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.

I'm not familiar with WebSockets. I'll take a look at the PR/review. If WebSockets are another form of client session analogous to HTTP2 and sessionized HTTP/1.x, then generalizing the ClientProtocolGet makes sense.

The reason I believe this change is necessary is that plugins do not have
any clean way to access this data
What data are you looking for? Whether the transaction is part of a HTTP/2 
session? Anything else?

( I am not sure if there is any at all)
and for one of the plugins I am working on it is crucial that this
information is logged. A specific example would be a plugin that hooks on
TXN_START and logs the protocol string.This function provides a simple
abstraction over the underlying method, it is as simple to use as it can
get, and therefore I believe it is a reasonable solution to the problem.

JIRA: https://issues.apache.org/jira/browse/TS-4703
PR: https://github.com/apache/trafficserver/pull/829

Thank you for your time and consideration! Please let me know if you have
any questions.
Yours Sincerely,
Petar Penkov

Reply via email to