Declaring acceptable types of file content
Accept Types
Preliminaries
This note describes how the server handles the browser's accept-types request header to allow the browser and server to agree on their understanding of what the inner contents of each file contains.
Browser and server capabilities do not always align 100%. Both the browser and server must agree on their understanding of what the inner contents of each file contains, they should not guess.
The HTTP accept-types request header is used by the browser to inform the server of its capabilities. The server's configuration file is used by the webmaster to declare its capabilities.
When requesting a file with a GET method, the server negotiates with the browser to determine which MIME-types are acceptable. See the separate note about Content Negotiation for a description of how that occurs.
GET requests for files whose mime-type is not acceptable to the browser are denied with a 406 response code.
When uploading a file with a PUT method, the server can selectively decide what types of files are acceptable. For example, if a server is able to handle TIFF images, it needs to be configured with an image/tiff entry in the accept-types section.
PUT requests for files whose mime-type is not acceptable to the server are denied with a 406 response code.
Configuration
The accept-types configuration section is used to declare which types can be negotiated. It comprises a collection of two-part entries: the left hand side is the literal string mime-type, and the right-hand side is a MIME-type that adheres to the IETF RFC 6838 specifications.
Placement
The accept-types configuration sections may appear in either the server section or a host section. When values occur in both the server and host sections, they are merged according to the standard rules defined for the merge attribute.
Information Headers
A rw-no-acceptable-type information header is added to responses whose requests are not acceptable.
EBNF
| SP | ::= | U+20 |
| CR | ::= | U+0D |
| SOLIDUS | ::= | U+2F |
| ASTERISK | ::= | U+2A |
| LEFT-CURLY-BRACKET | ::= | U+7B |
| RIGHT-CURLY-BRACKET | ::= | U+7D |
| media-type | ::= | 'text' | 'application' | 'image' | 'audio' | 'video' | 'multipart' |
| subtype | ::= | (ALPHA | DIGIT | †)* |
| MIME-type | ::= | media-type SOLIDUS subtype |
| accept-type-entry | ::= | 'mime-type' SP* MIME-type CR |
| accept-types-section | ::= | 'accept-types' SP LEFT-CURLY-BRACKET CR accept-type-entry* RIGHT-CURLY-BRACKET CR |
† See section 4.2 of RFC 6838 for exact rules
Cookbook
Example 1: MIME-types declared for browser accept-types negotiation
server {
accept-types {
mime-type text/html
mime-type text/plain
mime-type text/css
mime-type application/xhtml+xml
mime-type application/xml
mime-type application/json
mime-type application/javascript
mime-type application/pdf
mime-type image/png
mime-type image/jpeg
mime-type image/gif
mime-type image/svg+xml
mime-type image/webp
mime-type audio/webm
mime-type audio/ogg
mime-type audio/mpeg
mime-type audio/wav
mime-type audio/flac
mime-type video/webm
mime-type video/ogg
mime-type video/mp4
}
}
Review
Key points to remember:
- The server will respond with status code
200for any request whoseaccept-typematches a configured mime-type, either exactly or through wildcards. - The server will respond with status code
406andrw-no-acceptable-typeinformation header for requests that do not match any configured mime-type.
