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 (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 >> <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/CAPq58w7adWwvNAa1mX1%3DjEgwo7MiEaEXMwUPk7BCqeFNoSFW7A%40mail.gmail.com.
