trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Susan Hinrichs <shinr...@network-geographics.com>
Subject Re: TS-4703 && PR-829
Date Thu, 28 Jul 2016 14:29:17 GMT


On 7/28/2016 5:05 AM, James Peach wrote:
>> On Jul 28, 2016, at 7:33 PM, James Peach <jpeach@apache.org> wrote:
>>
>>
>>> On Jul 28, 2016, at 5:50 AM, Petar Bozhidarov Penkov <ppenkov@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


Mime
View raw message