Subject: WGLC for HTTP Priorities

From: Tommy Pauly <[email-masked]>
Date: Tue, 05 Oct 2021 16:15:48 -0700

Hello all,

Thanks to everyone who joined our interim calls last week!

This email starts a working group last call for draft-ietf-httpbis-priority, "Extensible Prioritization Scheme for HTTP”.

https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/ <https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/>
https://www.ietf.org/archive/id/draft-ietf-httpbis-priority-06.html <https://www.ietf.org/archive/id/draft-ietf-httpbis-priority-06.html>

Please review the document and reply to this email with your comments, and if you think this document is ready to progress. You can also file issues with the tag “priorities” at https://github.com/httpwg/http-extensions/issues <https://github.com/httpwg/http-extensions/issues>.

This last call will be open for two weeks, ending on Wednesday, October 20.

Best,
Tommy

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Fri, 15 Oct 2021 15:35:28 +0000

Hi,

I had a few comments on the draft, but in general it seems fine.

Section 1:
- It might be useful to mention something to the effect of 'Expressing priority is only a suggestion’ as is later detailed in section 10.

Section 4:
"If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field.”
- So an intermediary not using multiplexed HTTP can change the Priority header field?

Section 10:
- It could be useful to expand the PTO acronym

I was curious if there were any open implementations available of this in a server/proxy?

Thanks,

Piers

On 6 Oct 2021, at 00:15, Tommy Pauly <[email-masked]<mailto:[email-masked]>> wrote:

Hello all,

https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/
https://www.ietf.org/archive/id/draft-ietf-httpbis-priority-06.html

Please review the document and reply to this email with your comments, and if you think this document is ready to progress. You can also file issues with the tag “priorities” at https://github.com/httpwg/http-extensions/issues.

Best,
Tommy

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 15 Oct 2021 17:08:23 +0100

Hi Piers,

Thanks for the feedback! Responses in line

On Fri, Oct 15, 2021 at 4:39 PM Piers O'Hanlon <[email-masked]>
wrote:

> - It might be useful to mention something to the effect of 'Expressing
> priority is only a suggestion’ as is later detailed in section 10.
>

This has been raised by some others too. We can do a better job of making
that clear up front. Earlier today I already filed a PR to do that, please
take a look https://github.com/httpwg/http-extensions/pull/1752

> Section 4:
> "If intermediaries want to specify prioritization on a multiplexed HTTP
> connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT
> change the Priority header field.”

 This sounds related to the issue on
https://github.com/httpwg/http-extensions/issues/1715. Please take a look
at this PR which touches the text to let us know if it addresses your
question https://github.com/httpwg/http-extensions/pull/1735

> - It could be useful to expand the PTO acronym

Agreed, I just made https://github.com/httpwg/http-extensions/pull/1753

> I was curious if there were any open implementations available of this in

The cloudflare quiche library supports setting stream priorities as a local
transport layer API. We expose this up to the H3 layer so that it can set
response priorities. We delegate the parsing of HTTP request headers to
applications. The quiche example HTTP/3 server application [1] can read the
Priority header or a special (custom and non-standard) querystring format
(?u={val}&i={val}). I beleive nghttp3 [2] and h2o have support. Chrome has
some support on the client side, not sure about the status of Google's
server side though.

Cheers,
Lucas

[1] - https://github.com/cloudflare/quiche#command-line-apps
[2] -
https://github.com/ngtcp2/nghttp3/blob/cecc6791c7b1ffe8a1ddbc7c27cbea6c341afb89/README.rst#http3

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Fri, 15 Oct 2021 16:57:58 +0000

Hi Lucas,

On 15 Oct 2021, at 17:08, Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:

Hi Piers,

On Fri, Oct 15, 2021 at 4:39 PM Piers O'Hanlon <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Section 1:

This has been raised by some others too. We can do a better job of making that clear up front. Earlier today I already filed a PR to do that, please take a look https://github.com/httpwg/http-extensions/pull/1752

That text looks good.

Section 4:

 This sounds related to the issue on https://github.com/httpwg/http-extensions/issues/1715. Please take a look at this PR which touches the text to let us know if it addresses your question https://github.com/httpwg/http-extensions/pull/1735

Yes that’s removed the ambiguity.

Section 10:

Ok

The cloudflare quiche library supports setting stream priorities as a local transport layer API. We expose this up to the H3 layer so that it can set response priorities. We delegate the parsing of HTTP request headers to applications. The quiche example HTTP/3 server application [1] can read the Priority header or a special (custom and non-standard) querystring format (?u={val}&i={val}). I beleive nghttp3 [2] and h2o have support. Chrome has some support on the client side, not sure about the status of Google's server side though.

Thanks. It raises a question of how client web page/JS requests/signals priority - With H2 it was mainly down to the Browser developers but with this header based approach these can be added by JS, though it’s not clear how one invokes the use of a PRIORITY_UPDATE frame or would that just be down to the Browser client logic?

Best,

Piers

Cheers,
Lucas

[1] - https://github.com/cloudflare/quiche#command-line-apps
[2] - https://github.com/ngtcp2/nghttp3/blob/cecc6791c7b1ffe8a1ddbc7c27cbea6c341afb89/README.rst#http3

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 15 Oct 2021 18:12:59 +0100

Hi Piers,

> Hi Lucas,
Thanks. It raises a question of how client web page/JS requests/signals
> priority - With H2 it was mainly down to the Browser developers but with
> this header based approach these can be added by JS, though it’s not clear
> how one invokes the use of a PRIORITY_UPDATE frame or would that just be
> down to the Browser client logic?
>

That's something tangential to the protocol spec here but yes it would be
of interest to know how different browsers behave in this respect. For
instance, there's been some renewed interest in the Priority hints API [1]
im Chrome lately but it is not a direct mapping to this scheme.

Cheers
Lucas

[1] - https://developers.google.com/web/updates/2019/02/priority-hints

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Oct 2021 09:06:32 -0700

Thanks to everyone who provided feedback on the list and on GitHub!

We’ve had several issues opened, and the authors are planning on doing an editorial revision and proposing some more substantive changes to the list.

You can see the current issues list here: https://github.com/httpwg/http-extensions/issues?q=is%3Aopen+is%3Aissue+label%3Apriorities <https://github.com/httpwg/http-extensions/issues?q=is:open+is:issue+label:priorities>

Best,
Tommy

> On Oct 5, 2021, at 4:15 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hello all,
>