Intent to Prototype: 'priority' HTTP request header

[Patrick Meenan]

Contact emails

pme...@google.com

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>Loader

Motivation

Chrome currently sends priority frames for HTTP/3 but does not send the HTTP header (and does not prevent application code from writing the header). This will bring Chrome in-line with Safari and Firefox which already send the request header (See this article for more details on the current state of things).

TAG review status

Not applicable - IETF standard

Risks

Minimal risk as Firefox and Safari already send the header for HTTP/3 requests. There should be no additional fingerprinting surface as the same information is included in the priority frame that is already sent.

The main risk comes with sending the header on HTTP/1.1 requests where the other browsers do not currently send it and there is less use for it.

There is also a risk that some servers may choose to only implement header-based prioritization and not support frame-based priority updates on HTTP/3 but that would still be better than Chrome not benefitting from any prioritization.

Interoperability and Compatibility

Gecko: Shipped
WebKit: Shipped
Web developers: No signals

WebView application risks

None

Debuggability

The request headers are visible in dev tools and Netlog (which also includes the priority frames).  Actual server prioritization is dependent on the edge server that any given request flows through and is not particularly debuggable from the client.

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

No. The values selected for the priorities differ by browser (by design).

Requires code in //chrome?

False

Tracking bug

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5109106573049856

This intent message was generated by Chrome Platform Status.