Intent to Experiment: 'priority' HTTP request header

[Patrick Meenan]

Contact emails

pme...@google.com

Explainer

None

Specification

https://datatracker.ietf.org/doc/rfc9218

Summary

This feature adds the 'priority' request header for all HTTP requests with the priority information for the request at the time that it was sent. RFC 9218 (Extensible Prioritization Scheme for HTTP) defines a 'priority' HTTP request header to use for signaling request priority to origins (and intermediaries). It also defines negotiation processes and protocol-level frames for HTTP/2 and HTTP/3 to carry the same priority information. The header can only signal the initial priority for a resource when it was first requested while the frame-based mechanisms allow for modifying the priority after the fact. The header can operate end-to-end to the origin servers (and provide a mechanism for the origin to override the priority if recognized by intermediaries) while the frames are limited to operating on a link level. This feature is specifically for supporting the header-based prioritization scheme.

Blink component

Blink>Network

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping
WebKit: Shipped/Shipping
Web developers: No signals
Other signals:

Security

The priority information for a given request is already exposed in HTTP/2 and HTTP/3 in the frame-based priority fields (and weights in HTTP/2). This moves the same information directly into the headers for HTTP/2 and HTTP/3 only.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

Enable the header for a sample of the population and make sure there is no negative feedback before turning on globally.

Ongoing technical constraints

None

Debuggability

The "Priority" header is exposed in both the Dev Tools network panel (in the Request Headers) and in the Netlog.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

HTTP headers (and protocols) are not testable in Web Platform Tests.

Flag name on chrome://flags

Finch feature name

PriorityHeader

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1404785

Estimated milestones

DevTrial on desktop

119

DevTrial on Android

119

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5109106573049856

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/eEeDzwtw5v0

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Why has this not been sent to the TAG?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w5KJijit8ObBhWKzCnLjro7jSfAsxfPPZ66NwmTO_ZT%3Dg%40mail.gmail.com.

[Yoav Weiss]

Thanks for adding that support!

On Mon, Oct 9, 2023 at 10:40 PM Patrick Meenan <pme...@chromium.org> wrote:

Contact emails

pme...@google.com

Explainer

None

Can you briefly describe what the header parts are good for, and how would developers use them?

 

Specification

https://datatracker.ietf.org/doc/rfc9218

Summary

This feature adds the 'priority' request header for all HTTP requests with the priority information for the request at the time that it was sent. RFC 9218 (Extensible Prioritization Scheme for HTTP) defines a 'priority' HTTP request header to use for signaling request priority to origins (and intermediaries). It also defines negotiation processes and protocol-level frames for HTTP/2 and HTTP/3 to carry the same priority information. The header can only signal the initial priority for a resource when it was first requested while the frame-based mechanisms allow for modifying the priority after the fact. The header can operate end-to-end to the origin servers (and provide a mechanism for the origin to override the priority if recognized by intermediaries) while the frames are limited to operating on a link level. This feature is specifically for supporting the header-based prioritization scheme.

Blink component

Blink>Network

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping
WebKit: Shipped/Shipping

Any links that show this is shipping?

I see some evidence that this is available behind a flag in Safari, but nothing beyond that.

 

Web developers: No signals
Other signals:

Security

The priority information for a given request is already exposed in HTTP/2 and HTTP/3 in the frame-based priority fields (and weights in HTTP/2). This moves the same information directly into the headers for HTTP/2 and HTTP/3 only.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

Enable the header for a sample of the population and make sure there is no negative feedback before turning on globally.

Ongoing technical constraints

None

Debuggability

The "Priority" header is exposed in both the Dev Tools network panel (in the Request Headers) and in the Netlog.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

HTTP headers (and protocols) are not testable in Web Platform Tests.

I don't think that's correct. You could create custom handlers that would reflect the request's priority header in the response.

  

Flag name on chrome://flags

Finch feature name

PriorityHeader

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1404785

Estimated milestones

DevTrial on desktop

119

DevTrial on Android

119

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5109106573049856

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/eEeDzwtw5v0

This intent message was generated by Chrome Platform Status.

--

[Yoav Weiss]

On Tue, Oct 10, 2023 at 8:27 AM Alex Russell <sligh...@chromium.org> wrote:

Why has this not been sent to the TAG?

There's no TAG requirement for an I2E, and this is defined as part of the IETF, so outside of the TAG's "jurisdiction".

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQiO3mJB-NnBPaDU6fNTHNzxgy%2B-%3D-Proz-sGZVVgVk-MA%40mail.gmail.com.

[Patrick Meenan]

On Tue, Oct 10, 2023 at 3:18 AM Yoav Weiss <yoav...@chromium.org> wrote:

Can you briefly describe what the header parts are good for, and how would developers use them?

There are 2 parts to the header which is formatted as a structured-field dictionary (comma-separated entries with each entry being key=value.

The 2 keys are:

u (urgency) = numeric from 0 to 7 with 0 being the highest priority and 7 being the lowest (and 3 being the default).

i (incremental) = boolean to specify if the response should be interleaved with other responses of the same priority (defaults to disabled).

e.g. "priority: u=1, i" would indicate a high priority request that allows for interleaving.

I'm not expecting a lot of direct web developer use of it. It's more for the HTTP/2 and HTTP/3 servers to use to prioritize multiplexed responses and to align with Firefox and Safari for any servers that prefer to just use the headers for prioritization and not do the frame-level priorities (which Chrome is the only browser to use for HTTP/3).

In theory, a web developer could prioritize the processing of higher-priority requests differently than low-priority requests but most cases where that makes sense would probably be relying on other headers like "Sec-Purpose: prefetch" if they want to segregate their infrastructure and de-prioritize background fetches.

 

 

Gecko: Shipped/Shipping
WebKit: Shipped/Shipping

Any links that show this is shipping?

I see some evidence that this is available behind a flag in Safari, but nothing beyond that.

Safari removed the explicit flag in 16.4 for HTTP/3 and enabled it for a subset of users but I don't see mention of it in the release notes in 16.4 or later so the status hasn't been communicated externally. When HTTP/3 does get used in Safari, the Priority header is always enabled. I have a test page here (https://headers.patrickmeenan.com/) that has HTTP/3 enabled and will echo the protocol and headers that were received by the server. If you can get Safari to use HTTP/3 (at a minimum you have to turn off private relay) then it will show the Priority header.

Firefox pretty reliably switches to HTTP/3 on the test page after a few reloads and will show the header.

The test page also tests what the browser does if fetch() is called with a priority header that is application-set.  Safari (and the Chrome implementation) defer to the application-set value and do not add the protocol-specific value in that case. Firefox sends 2 Priority headers.

 

 

Is this feature fully tested by web-platform-tests?

No

HTTP headers (and protocols) are not testable in Web Platform Tests.

I don't think that's correct. You could create custom handlers that would reflect the request's priority header in the response.

Sorry, headers themselves are testable but this header specifically requires a HTTP/3 server for cross-browser testing (or at least a HTTP/2 server for Chrome testing) AFAIK, the server in wpt can't test HTTP/3. Even if it could, the actual priority values themselves aren't standardized and wouldn't be testable in wpt (other than their presence).

If the header is added to HTTP/1.1 requests (or if at least HTTP/2 is supported by the WPT server) then we could use the priority header to test fetchpriority and make sure high/low fetchpriority is reflected as a relative difference in the priority at the network level but that's not explicitly testing this header (and not currently possible).

 

  

As far as TAG review, as Yoav mentioned, this is an IETF spec and Chrome is actually catching up to support that has already shipped in other browsers. That said, it might not be a bad idea to get it on the TAG's radar to get some consistency in the fetch() behavior since "Priority" isn't currently a reserved header and the browsers differ in how they behave if the header is explicitly set.  Not sure if that's more appropriate for TAG or just for an issue on the fetch spec repository. 

[Yoav Weiss]

One last question: what milestones are you planning to run this experiment on?

On Tuesday, October 10, 2023 at 7:02:51 PM UTC+2 Patrick Meenan wrote:

On Tue, Oct 10, 2023 at 3:18 AM Yoav Weiss <yoav...@chromium.org> wrote:

Can you briefly describe what the header parts are good for, and how would developers use them?

There are 2 parts to the header which is formatted as a structured-field dictionary (comma-separated entries with each entry being key=value.

The 2 keys are:

u (urgency) = numeric from 0 to 7 with 0 being the highest priority and 7 being the lowest (and 3 being the default).

i (incremental) = boolean to specify if the response should be interleaved with other responses of the same priority (defaults to disabled).

e.g. "priority: u=1, i" would indicate a high priority request that allows for interleaving.

I'm not expecting a lot of direct web developer use of it. It's more for the HTTP/2 and HTTP/3 servers to use to prioritize multiplexed responses and to align with Firefox and Safari for any servers that prefer to just use the headers for prioritization and not do the frame-level priorities

So this will be sent in both H2 and H3?

 

(which Chrome is the only browser to use for HTTP/3).

Do you know why other browsers don't implement the frame version?

 

In theory, a web developer could prioritize the processing of higher-priority requests differently than low-priority requests but most cases where that makes sense would probably be relying on other headers like "Sec-Purpose: prefetch" if they want to segregate their infrastructure and de-prioritize background fetches.

 

 

Gecko: Shipped/Shipping
WebKit: Shipped/Shipping

Any links that show this is shipping?

I see some evidence that this is available behind a flag in Safari, but nothing beyond that.

Safari removed the explicit flag in 16.4 for HTTP/3 and enabled it for a subset of users but I don't see mention of it in the release notes in 16.4 or later so the status hasn't been communicated externally. When HTTP/3 does get used in Safari, the Priority header is always enabled. I have a test page here (https://headers.patrickmeenan.com/) that has HTTP/3 enabled and will echo the protocol and headers that were received by the server. If you can get Safari to use HTTP/3 (at a minimum you have to turn off private relay) then it will show the Priority header.

Firefox pretty reliably switches to HTTP/3 on the test page after a few reloads and will show the header.

The test page also tests what the browser does if fetch() is called with a priority header that is application-set.  Safari (and the Chrome implementation) defer to the application-set value and do not add the protocol-specific value in that case. Firefox sends 2 Priority headers.

Would be great to get an official word from them on what they are shipping and when. Maybe file (non-blocking) positions on this? 

[Patrick Meenan]

On Wed, Oct 11, 2023 at 11:04 AM Yoav Weiss <yoav...@chromium.org> wrote:

So this will be sent in both H2 and H3?

Yes. As it stands right now, the Priority header will be sent in all cases where we prioritize (and already send frame-level priorities) on multiplexed connections (HTTP/2 and HTTP/3).  The benefit of sending it on HTTP/2 is that it will let any endpoints that are not supporting the HTTP/2 dependency tree to start implementing support for at least initial priorities if they are interested in doing it (and for CDN's like Cloudflare that apply the extensible priorities-type scheme to HTTP/2 already to use explicit params instead of translating the browser-specific trees and weights from HTTP/2 into equivalent priorities).  Eventually it would be worth experimenting with HTTP/2 priority update frames so sites that DO already support prioritization could switch completely over but that's out of scope for this particular change.

 

 

(which Chrome is the only browser to use for HTTP/3).

Do you know why other browsers don't implement the frame version?

The frame version is mostly in place to support reprioritizing in-flight requests (though it technically supports being used for an initial priority which is what Chrome does since Chrome also supports reprioritization). I'm not sure why other browsers decided to use the headers rather than the frames but there are a lot of possibilities where it makes sense (if the headers are easier to add, if the layering is such that QUIC is done in the OS-layer and priorities are done by the browser).

  

Would be great to get an official word from them on what they are shipping and when. Maybe file (non-blocking) positions on this? 

Position for extensible priorities specifically or HTTP/3? Has Safari ever committed publicly to timelines? Position appears to be more than supportive since it's been implemented since Safari 14 or 15, the feature flag removed in 16.4 and it's mostly just questions around the rollout. There's some level of interaction with their IP-blinding proxy work that make it a bit more complicated.

[Patrick Meenan]

Sorry, forgot to mention the milestone - 120 for running the experiment. The code is in place to run the experiment as of 119 but since it hasn't run enabled in dev channel and 119 is in Beta now, the plan is to experiment in 120.

[Yoav Weiss]

LGTM to experiment in 120

[Patrick Meenan]

Issue has been filed with the whatwg spec to specify the behavior of the priority header, either by adding it to the forbidden header list or by defining how the networking layer should behave if there is an application-supplied value.