Bringing this conversation back to life. We'd like to open source a
plugin which relies on this API (or something like it). There has been
discussion on the PR which James requests that we bring back to the
mailing list.
To catch everyone up to speed with the PR discussion
(https://github.com/apache/trafficserver/pull/829)
Alan said " I have to disagree with James. Once upon a time, this worked
(if any one remember the "proto stack" thing). It was an explicit goal
of the TS-3612 work to get this capability back. It is useful in a
number of situations to be able to know what protocol the user agent is
using to talk to ATS. I know I took no small amount of heat when I broke
this originally."
James said "My main objection to this API is that is makes promises it
doesn't (maybe can't) keep. It just tells you whether this is HTTP/1 or
HTTP/2. That's fine, and an API that does that it also fine, but that
should look different to this.
James, do you have a suggestion for a superior API to give the plugin
information about the client protocol associated with the session? What
information does it not provide that it is promising?
On 7/28/2016 7:28 PM, James Peach wrote:
On Jul 29, 2016, at 12:29 AM, Susan Hinrichs <shinr...@network-geographics.com>
wrote:
On 7/28/2016 5:05 AM, James Peach wrote:
On Jul 28, 2016, at 7:33 PM, James Peach <jpe...@apache.org> wrote:
On Jul 28, 2016, at 5:50 AM, Petar Bozhidarov Penkov <ppen...@stanford.edu>
wrote:
Hello,
I am writing in accordance with the referenced Pull Request and JIRA issue.
I am proposing a GET-er method for Transactions's underlying protocol. This
relates to TS-2987 and is effectively one of the proposed solutions, a
wrapper around ProxyClientTransaction::get_protocol_string() . The proposed
API is as follows:
*tsapi const char *TSHttpTxnClientProtocolGet(TSHttpTxn txnp);*
**name credit goes to Susan Hinrichs and Alan Carroll*
Hi Petar,
I’m not sure that this is the right approach. get_protocol_string() simply
distinguishes HTTP/2 sessions, so it it not something that I think is ready to
become API. Since we already have an abstraction for HTTP versions (see
TSHttpHdrVersionGet), maybe a better approach is to expose a convenience API
that returns the transaction HTTP version as a TS_HTTP_VERSION() constant.
We also have a pending review for TSHttpTxnIsWebsocket(), which seems to
overlap with this proposal.
Yes, we would like to know whether the transaction is part of a Http/1.x
session or a Http/2 session (or whatever else comes up in the future.
Do you have a concrete use case for knowing this?
J
