Some notes:
maskit - we can just add another enum value. You're right that it should
probably not be "ProtocolType" because it may be unrelated. "PriorityType"
would probably be better as a name.
There shouldn't be a "0_9" - I thought we had agreed to not support that at
all anymore.
There shoul
Actually, I don't understand TSHttpProtocolType. Shouldn't it be
StructureType? Let's say we support a new priority scheme that is available
on both H2 and H3. What would be the TSHttpProtocolType for it?
Masakazu
On Wed, Sep 2, 2020 at 9:37 AM Masakazu Kitajo wrote:
> +1 I'm ok with the new fu
+1
On Tuesday, September 1, 2020, 03:49:43 PM PDT, Masaori Koshiba
wrote:
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
TSHttpStreamId *stream_id);
> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
TSHttpPriority *priority);
+1
On Wed, Sep 2, 202
+1 I'm ok with the new function signatures that use abstract structures.
However, I'm not sure if we really need that flexibility for Stream ID, I
can't say 64-bit is big enough, but I think extensibility is not
everything. Usability matters. Should we prepare for 128-bit stream ids
now? Would we
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
TSHttpStreamId *stream_id);
> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
TSHttpPriority *priority);
+1
On Wed, Sep 2, 2020 at 7:35 AM Brian Neradt wrote:
> I updated the protocol draft with this input (noti
I updated the protocol draft with this input (notice I kept the updated API
implementation as the second commit in the PR for the sake of comparison):
https://github.com/apache/trafficserver/pull/7149
The API now looks like the following:
tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn tx
This sounds good to me. This essentially puts the type parameter in the
structure itself rather than as a separate parameter to the functions.
On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
wrote:
> Sorry for chiming in late -
>
> Note this is extremely similar to IP addresses and I recommend we us
Sorry for chiming in late -
Note this is extremely similar to IP addresses and I recommend we use the
same solution. That is, there is a class HttpPriority which has just a
type/style/family value and possibly a length. This is an abstract class
like sockaddr (which no one actually instantiates).
Thank you Sudheer, this is helpful.
Considering Masaori's input, it sounds like it would be wise to amend
TSHttpTxnClientPriorityGet to just take a single, generic priority opaque
structure:
tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
TSHttpProtocolType type, void *stream_id);
>> (primary reason for that being let the user have "control" on what they
>>want to retrieve).
And of course, the API shall return TS_ERROR, if the passed in protocol "type"
is not correct for the given TXN.
On Tuesday, September 1, 2020, 08:45:21 AM PDT, Sudheer Vinukonda
wrote:
+1 to use opaque structures and use protocol "type" as the "key".
I'd slightly prefer the caller pass in the protocol type rather than letting TS
automatically determine that (primary reason for that being let the user have
"control" on what they want to retrieve).
For e.g
tsapi TSReturnCode
> On Sep 1, 2020, at 01:20, Masaori Koshiba wrote:
>
> I totally agree with less API is better.
>
>> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
> uint64_t *stream_id);
>
> Stripping "Http2" looks reasonable. We can use this API for protocols that
> have stream id.
>
>> t
I totally agree with less API is better.
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
uint64_t *stream_id);
Stripping "Http2" looks reasonable. We can use this API for protocols that
have stream id.
> tsapi TSReturnCode TSHttpTxnClientPriorityGet(TSHttpTxn txnp,
uint64_t *stre
Thanks all, this is good feedback. It sounds like we're in agreement on
dropping the explicit reference to Http2 so this can accommodate future
protocols. Considering this and the observation that stream_id is 62 bits
for HTTP/3, the output parameters should be increased in size accordingly.
That w
Right, it does make sense to have a generic API naming (and remove http2
reference from it), but I'm thinking it should still allow to pass in some
context object (we may define an interface for it, with "protocol" being a
mandatory field) to be able to continue using it in the future as well a
Sudheer,
Would a separated API to get the actual protocol active for the given
request satisfy you? I don't understand how indicating the actual protocol
helps something.
I think I understand your concern. Future protocols may need different
params, or might have different representations. Howeve
+1
-Bryan
> On Aug 28, 2020, at 7:40 AM, Brian Neradt wrote:
>
> Hi dev@trafficserver.apache.org,
>
> It would be helpful to add HTTP/2 stream and priority support to Traffic
> Dump. In order for the plugin to access this information, I propose adding
> the following two functions to the TS A
> On Aug 30, 2020, at 19:48, Masakazu Kitajo wrote:
>
> I think we should avoid adding APIs just for HTTP/2 unless it's really
> HTTP/2 specific. Are we going to add TSHttpTxnClientHttp3StreamIdGet and
> TSHttpTxnClientHttp3PriorityGet as well?
>
> I'd omit the "2" in the API names, and reph
Hmm, it does sound appealing to avoid having to duplicate API for common
attributes between H/2 and H/3, but, I'm thinking the API should still somehow
explicitly indicate (either via an input param or an output param) the actual
protocol active for the given request. It seems a bit too confusi
And there is a proposal for a new priority scheme that may be used for both
H2 and H3.
https://tools.ietf.org/html/draft-ietf-httpbis-priority-01
I haven't read it, but it would be nice if the TS API could be compatible
with the new scheme.
On Mon, Aug 31, 2020 at 10:48 AM Masakazu Kitajo wrote:
I think we should avoid adding APIs just for HTTP/2 unless it's really
HTTP/2 specific. Are we going to add TSHttpTxnClientHttp3StreamIdGet and
TSHttpTxnClientHttp3PriorityGet as well?
I'd omit the "2" in the API names, and rephrase the API doc like:
This API returns an error if the provided trans
+1
On Fri, Aug 28, 2020 at 3:23 PM Sudheer Vinukonda
wrote:
> +1.
> Sounds reasonable to me.
>
>
> On Friday, August 28, 2020, 07:41:18 AM PDT, Brian Neradt <
> brian.ner...@gmail.com> wrote:
>
> Hi dev@trafficserver.apache.org,
>
> It would be helpful to add HTTP/2 stream and priority sup
+1.
Sounds reasonable to me.
On Friday, August 28, 2020, 07:41:18 AM PDT, Brian Neradt
wrote:
Hi dev@trafficserver.apache.org,
It would be helpful to add HTTP/2 stream and priority support to Traffic
Dump. In order for the plugin to access this information, I propose adding
the follo
23 matches
Mail list logo
