Re: HTTP Priority - proposal to support headers and frames

I support this clarification and supporting both and documenting their
properties is the right way forward.

This clarifies/enables some use cases we were having trouble with, such as
allowing a proxy to both indicate the original request priority to an
origin(via the header) as well as prioritize requests within a multiplexed
proxy to origin connection(via the PRIORITY_UPDATE frame).

Thanks for moving this draft forward.

On Mon, May 4, 2020 at 12:07 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hello WG,
>
> If you recall, in March we published draft-ietf-http-priority-00, which
> fixed a few issues that we gave an overview on the mailing list [1].
>
> One of the remaining issues is concerned about the use of headers vs
> frames. Tracking the range of different threads, the answer seems to having
> an ability to use either.
>
> PR 1167 is a proposal that tweaks the PRIORITY_UPDATE frame in a few ways.
> The most interesting tweak is to make it more explicit that the frame can
> be used to signal the initial priority of a request [2], this frame can
> only be sent on stream 0 / control stream. This reflects my understanding
> of how Chrome is using the PRIORITY_UPDATE frame today.
>
> This proposal avoids sending a new priority frame on the request stream.
> Doing that adds some complication for H2. Further, H3 would have to deal
> with the possibility of out-of-order delivery anyway, so having another
> frame does not help it.
>
> We welcome comments on the issue, the PR or in this thread.
>
> Cheers
> Lucas
>
> [1] -
> https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0171.html
> [2] - https://github.com/httpwg/http-extensions/pull/1167
>