> 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