-
Notifications
You must be signed in to change notification settings - Fork 22.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP Priority header #34399
Merged
Merged
HTTP Priority header #34399
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
875fc4a
HTTP Priority header
hamishwillee 095e0c3
Update files/en-us/web/http/headers/index.md
hamishwillee 6aec65d
Update files/en-us/web/http/headers/priority/index.md
hamishwillee d77cd21
Update files/en-us/web/http/headers/priority/index.md
hamishwillee 701c4bc
Merge branch 'main' into ff128http_priority
bsmth 662ae9f
Apply suggestions from code review
hamishwillee File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,156 @@ | ||
--- | ||
title: Priority | ||
slug: Web/HTTP/Headers/Priority | ||
page-type: http-header | ||
browser-compat: http.headers.Priority | ||
--- | ||
|
||
{{HTTPSidebar}} | ||
|
||
The **`Priority`** HTTP header is sent in requests to indicate a client's preference for the priority order at which the response containing the requested resource should be sent, relative to other resource requests on the same connection. If the header is not specified in the request, a default priority is assumed. | ||
|
||
The server is not bound by client prioritization and might only use client requests as hints for its own prioritization process. | ||
For example, a server may know that a specific image is vital for user experience and should be sent at the highest priority. | ||
Server prioritization might also be affected by factors such as network congestion. | ||
|
||
This request may be cached, and the server is expected to control the cacheability or the applicability of the cached response using the header fields that control the caching behavior, such as {{HTTPHeader("Cache-Control")}} and {{HTTPHeader("Vary")}}. | ||
|
||
The server may also include this header in responses in order to indicate it has an interest in changing the prioritization. | ||
This information can then be used as an input to the prioritization process for caching servers and other servers that are forwarding the response. | ||
|
||
> **Note:** This header is one part of the "Extensible Prioritization Scheme for HTTP" defined in {{rfc("9218")}}. | ||
> There are also HTTP/2 and HTTP/3 `PRIORITY_UPDATE` frames that can be used to re-prioritize a resource request after it has been sent. | ||
> The request can be sent in any HTTP version. | ||
<table class="properties"> | ||
<tbody> | ||
<tr> | ||
<th scope="row">Header type</th> | ||
<td> | ||
{{Glossary("Request header")}}, | ||
{{Glossary("Response header")}} | ||
</td> | ||
</tr> | ||
<tr> | ||
<th scope="row">{{Glossary("Forbidden header name")}}</th> | ||
<td>no</td> | ||
</tr> | ||
</tbody> | ||
</table> | ||
|
||
## Syntax | ||
|
||
```http | ||
Priority: u=<priority> | ||
Priority: i | ||
Priority: u=<priority>, i | ||
``` | ||
|
||
## Directives | ||
|
||
- `u=<priority>` | ||
|
||
- : The "urgency" (`u`) parameter specifies a priority value `<priority>` for the resource. | ||
The value is an integer between 0 and 7 inclusive, in descending order of priority (0 is the highest urgency). | ||
The default priority value for requests is 3. | ||
There is no default priority value for responses: the absence of the header in a response indicates that the server has chosen not to modify the client priority. | ||
A priority of 7 should only be used for resources that are unlikely to affect the user experience, such as background tasks or delivery of software updates. | ||
|
||
Browsers should request documents that are likely to use other resources at the default priority level. | ||
The referenced resources should then be requested using values that reflect the relative impact on the user experience of their arrival time. | ||
|
||
Servers may have a different view on the priority than the client, and can respond with a different value in order to provide a priority hint to intermediate servers. | ||
The intermediate server may take this value into consideration along with the original request priority. | ||
The absence of the `Priority` header in the response indicates that the server chosen not to modify the client priority. | ||
|
||
- `i` | ||
|
||
- : The incremental (`i`) directive, if present, indicates than an HTTP response can be processed incrementally. | ||
|
||
Resources that can be processed incrementally are those where the recipient can potentially do something useful as soon as a chunk arrives, rather than waiting for the complete resource to be available. | ||
|
||
If a browser sets this directive then the server may choose to concurrently serve all incremental requests with the same urgency. | ||
This distributes the multiple requests across the connection bandwidth, with the result that all the requests start being processed earlier, but take longer in total to complete. | ||
|
||
If the browser does not set this directive then it is indicating that it will not process the resource incrementally. | ||
Servers should in this case send responses with the same urgency one by one, in the order in which their associated requests were generated. | ||
|
||
> **Note:** Servers are expected to ignore directives on this header that they do not understand. | ||
> New directives that are added in future are expected to be compatible with these existing directives so that they can be safely ignored. | ||
## Examples | ||
|
||
### Setting resource urgency | ||
|
||
The following example shows a request for an HTML file. | ||
The urgency isn't set, and so defaults to 3, with `i` being false. | ||
This is the normal setting for a document that owns other resources. | ||
|
||
```http | ||
:method = GET | ||
:scheme = https | ||
:authority = example.net | ||
:path = /index.html | ||
``` | ||
|
||
The request below is a possible follow-on request for a CSS file used by the HTML. | ||
The urgency is set to 2, indicating that the browser considers it to be quite high priority, but `i` is unset because the CSS file can't be handled incrementally. | ||
|
||
```http | ||
:method = GET | ||
:scheme = https | ||
:authority = example.net | ||
:path = /style.css | ||
priority = u=2 | ||
``` | ||
|
||
> **Note:** The requests above use the human-readable format from the HTTP/2 or HTTP/3 specifications. | ||
> The HTTP/1.1 format used in most of this documentation would be something like: | ||
> | ||
> ```http | ||
> GET /style.css HTTP/1.1 | ||
> Host: example.net | ||
> Priority: u=2 | ||
> ``` | ||
A response might look as shown below. | ||
Note that in this case the `priority` is not specified, indicating that the server did not feel that it needed to change the priority for intermediate servers. | ||
|
||
```http | ||
:status: 200 | ||
content-type: text/css | ||
content-length: 610 | ||
date: [current date] | ||
``` | ||
|
||
### Setting the incremental directive | ||
|
||
The header below shows a browser request for an image that can be rendered incrementally. | ||
In this case, the priority is set to 4 (lower than the default of 3), and `i` is set to indicate that the client can process the JPG file incrementally. | ||
|
||
```http | ||
:method = GET | ||
:path = /image.jpg | ||
:scheme = https | ||
:authority = example.net | ||
priority = u=4, i | ||
``` | ||
|
||
The server might send a response like the one below. | ||
In this case the priority is set to 1, indicating that the server has an understanding that particular image should be sent at high priority. | ||
|
||
```http | ||
:status: 200 | ||
content-type = image/jpeg | ||
content-length = 610 | ||
... | ||
priority = u=1, i | ||
``` | ||
|
||
## Specifications | ||
|
||
{{Specifications}} | ||
|
||
## Browser compatibility | ||
|
||
{{Compat}} |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, I chose to use the HTTP/2 spec human readable format here. We should consider moving to it in future. Main reason though is that even though this can be used in HTTP/1.1 the main benefits come in HTTP/2 and 3. Also the spec uses it :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have as nice syntax highlighting, but let's look at that again at some point. We might have the option for extending the block language as
http2
or something.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For sure. Apparently it isn't too hard to extend with regexp.