Re: HTTP Priority - proposal to support headers and frames

Ian Swett <ianswett@google.com> Tue, 05 May 2020 17:58 UTC

Resent-Date: Tue, 05 May 2020 17:55:44 +0000
Resent-Message-Id: <E1jW1nE-0008Qv-JY@lyra.w3.org>
MIME-Version: 1.0
References: <CALGR9ob6uU6QtSJA2_7O8PdkAz15Y3kZ1ORoCCfqqRWAU-cuhA@mail.gmail.com>
In-Reply-To: <CALGR9ob6uU6QtSJA2_7O8PdkAz15Y3kZ1ORoCCfqqRWAU-cuhA@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Tue, 05 May 2020 13:55:16 -0400
Message-ID: <CAKcm_gPhcrsUW4V6VE-hgQE+o=g3Bxit65pC3Fjzw6a_Ks8TJQ@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000006444fd05a4ea5a4f"
Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=ianswett@google.com; helo=mail-wr1-x429.google.com
Subject: Re: HTTP Priority - proposal to support headers and frames
Archived-At: <https://www.w3.org/mid/CAKcm_gPhcrsUW4V6VE-hgQE+o=g3Bxit65pC3Fjzw6a_Ks8TJQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

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
>

HTTP Priority - proposal to support headers and f… Lucas Pardue
Re: HTTP Priority - proposal to support headers a… Ian Swett