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/CAL5BFfXoJHeVc3_mPrtvuw93M19RF8Syn8QnJEVxMUJhpuUmUw%40mail.gmail.com.
