-
Notifications
You must be signed in to change notification settings - Fork 396
Define behavior for Priority request header #1718
Copy link
Copy link
Open
Labels
needs concrete proposalMoving the issue forward requires someone to figure out a detailed planMoving the issue forward requires someone to figure out a detailed planneeds testsMoving the issue forward requires someone to write testsMoving the issue forward requires someone to write teststopic: http
Metadata
Metadata
Assignees
Labels
needs concrete proposalMoving the issue forward requires someone to figure out a detailed planMoving the issue forward requires someone to figure out a detailed planneeds testsMoving the issue forward requires someone to write testsMoving the issue forward requires someone to write teststopic: http
Type
Fields
Give feedbackNo fields configured for issues without a type.
What is the issue with the Fetch Standard?
The
Priorityrequest 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
Priorityheader 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
Priorityheader.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
Priorityheader as part of the request.