- 1) Introduction
- 2) Notational Conventions and Generic Grammar
- 3) Protocol Parameters
- 4) HTTP Message
- 5) Request
- 6) Response
- 7) Entity
- 8) Connections
- 9) Method Definitions
- 10) Status Code Definitions
- 1) Informational 1xx
- 2) Successful 2xx
- 3) Redirection 3xx
- 4) Client Error 4xx
- 1) 400 Bad Request
- 2) 401 Unauthorized
- 3) 402 Payment Required
- 4) 403 Forbidden
- 5) 404 Not Found
- 6) 405 Method Not Allowed
- 7) 406 Not Acceptable
- 8) 407 Proxy Authentication Required
- 9) 408 Request Timeout
- 10) 409 Conflict
- 11) 410 Gone
- 12) 411 Length Required
- 13) 412 Precondition Failed
- 14) 413 Request Entity Too Large
- 15) 414 Request-URI Too Long
- 16) 415 Unsupported Media Type
- 17) 416 Requested Range Not Satisfiable
- 18) 417 Expectation Failed
- 5) Server Error 5xx
- 11) Access Authentication
- 12) Content Negotiation
- 13) Caching in HTTP
- 1) ..
- 2) Expiration Model
- 3) Validation Model
- 4) Response Cacheability
- 5) Constructing Responses From Caches
- 6) Caching Negotiated Responses
- 7) Shared and Non-Shared Caches
- 8) Errors or Incomplete Response Cache Behavior
- 9) Side Effects of GET and HEAD
- 10) Invalidation After Updates or Deletions
- 11) Write-Through Mandatory
- 12) Cache Replacement
- 13) History Lists
- 14) Header Field Definitions
- 1) Accept
- 2) Accept-Charset
- 3) Accept-Encoding
- 4) Accept-Language
- 5) Accept-Ranges
- 6) Age
- 7) Allow
- 8) Authorization
- 9) Cache-Control
- 10) Connection
- 11) Content-Encoding
- 12) Content-Language
- 13) Content-Length
- 14) Content-Location
- 15) Content-MD5
- 16) Content-Range
- 17) Content-Type
- 18) Date
- 19) ETag
- 20) Expect
- 21) Expires
- 22) From
- 23) Host
- 24) If-Match
- 25) If-Modified-Since
- 26) If-None-Match
- 27) If-Range
- 28) If-Unmodified-Since
- 29) Last-Modified
- 30) Location
- 31) Max-Forwards
- 32) Pragma
- 33) Proxy-Authenticate
- 34) Proxy-Authorization
- 35) Range
- 36) Referer
- 37) Retry-After
- 38) Server
- 39) TE
- 40) Trailer
- 41) Transfer-Encoding
- 42) Upgrade
- 43) User-Agent
- 44) Vary
- 45) Via
- 46) Warning
- 47) WWW-Authenticate
- 15) Security Considerations
- 16) Acknowledgments
- 17) References
- 18) Authors' Addresses
- 19) Appendices
- 20) Index
- 21) Full Copyright Statement
- 22) Acknowledgement
14.3 Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings (Section 3.5) that are acceptable in the response.
Accept-Encoding | = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" qvalue ] ) |
codings | = ( content-coding | "*" ) |
Examples of its use are:
Accept-Encoding: | compress, gzip |
Accept-Encoding: | |
Accept-Encoding: | * |
Accept-Encoding: | compress;q=0.5, gzip;q=1.0 |
Accept-Encoding: | gzip;q=1.0, identity; q=0.5, *;q=0 |
A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:
If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in Section 3.9, a qvalue of 0 means "not acceptable.")
The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
Note: If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display messages sent with other content-codings. The server might also make this decision based on information about the particular user-agent or client.
Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will not work and are not permitted with x-gzip or x-compress.