Issue has been filed <https://github.com/whatwg/fetch/issues/1718> 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.
On Wed, Oct 11, 2023 at 12:12 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > LGTM to experiment in 120 > > On Wed, Oct 11, 2023 at 6:11 PM Patrick Meenan <pmee...@chromium.org> > wrote: > >> 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. >> >> On Wed, Oct 11, 2023 at 11:04 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> 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 <yoavwe...@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 <https://datatracker.ietf.org/doc/html/rfc9218#name-urgency>) >>> = numeric from 0 to 7 with 0 being the highest priority and 7 being the >>> lowest (and 3 being the default). >>> i (incremental >>> <https://datatracker.ietf.org/doc/html/rfc9218#name-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? >>> >>> >>> >>> >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?No >>> >>> HTTP headers (and protocols) are not testable in Web Platform Tests. >>> >>> >>> I don't think that's correct. You could create custom handlers >>> <https://web-platform-tests.org/tools/wptserve/docs/handlers.html#python-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. >>> >>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w5aNdbEADdi_wOKfwT%2BDpZYzB8M4vZNjYiF0b1Ou6yF5A%40mail.gmail.com.
