You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Priority request header is part of RFC 9218 (Extensible HTTP Priorities) and sent by the networking layer when appropriate (for most browsers this is when using HTTP/3, Chrome may start sending it for HTTP/2 as well).
The header is not currently on the list of forbidden request headers and the behavior is undefined for how it interacts with a user-provided Priority header in fetch.
For actual prioritization, fetch provides RequestPriority (though it is not as granular) but applications may have their own use for the header name if they are already sending it.
It would be helpful to specify the behavior either by adding it to the forbidden header list or defining how the extensible priorities header should be treated if an application provides an explicit Priority header.
The current behavior in Firefox is to send both headers. In Chrome (behind a flag) the header will only be set by the networking stack if the application didn't include a Priority header as part of the request.
The text was updated successfully, but these errors were encountered:
Sec- makes sense if the header is meant to be forbidden.
I can't speak directly to the extensible priorities spec since I was mostly an observer while the process went through but the end-to-end header intentionally allows for overrides by the origin and it's not immediately clear that the intent wasn't also to allow for the value to be application-specified or at least overridden.
That said, it wouldn't hurt for both groups to align on when Sec- should be used and when it shouldn't. It also came up during discussions on compression dictionaries.
What is the issue with the Fetch Standard?
The
Priority
request header is part of RFC 9218 (Extensible HTTP Priorities) and sent by the networking layer when appropriate (for most browsers this is when using HTTP/3, Chrome may start sending it for HTTP/2 as well).The header is not currently on the list of forbidden request headers and the behavior is undefined for how it interacts with a user-provided
Priority
header in fetch.For actual prioritization, fetch provides RequestPriority (though it is not as granular) but applications may have their own use for the header name if they are already sending it.
It would be helpful to specify the behavior either by adding it to the forbidden header list or defining how the extensible priorities header should be treated if an application provides an explicit
Priority
header.The current behavior in Firefox is to send both headers. In Chrome (behind a flag) the header will only be set by the networking stack if the application didn't include a
Priority
header as part of the request.The text was updated successfully, but these errors were encountered: