Contact [email protected] Specificationhttps://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 componentBlink>Loader <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> 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 <https://calendar.perfplanet.com/2022/http-3-prioritization-demystified/#sec_rawdetails> for more details on the current state of things). TAG review statusNot 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No. The values selected for the priorities differ by browser (by design). Requires code in //chrome?False Tracking bughttps://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 <https://chromestatus.com/>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w73%3DCvHXdH94Y_uXta3Z6-gup%3D2%3Dvzf26TAUeoaEK-Urg%40mail.gmail.com.
