datavow.com - Documents

1) Introduction
- 1) Purpose
- 2) Requirements
- 3) Terminology
- 4) Overall Operation
2) Notational Conventions and Generic Grammar
- 1) Augmented BNF
- 2) Basic Rules
3) Protocol Parameters
- 1) HTTP Version
- 2) Uniform Resource Identifiers
- 3) Date/Time Formats
  - 1) Full Date
  - 2) Delta Seconds
- 4) Character Sets
  - 1) Missing Charset
- 5) Content Codings
- 6) Transfer Codings
  - 1) Chunked Transfer Coding
- 7) Media Types
  - 1) Canonicalization and Text Defaults
  - 2) Multipart Types
- 8) Product Tokens
- 9) Quality Values
- 10) Language Tags
- 11) Entity Tags
- 12) Range Units
4) HTTP Message
- 1) Message Types
- 2) Message Headers
- 3) Message Body
- 4) Message Length
- 5) General Header Fields
5) Request
- 1) Request-Line
  - 1) Method
  - 2) Request-URI
- 2) The Resource Identified by a Request
- 3) Request Header Fields
6) Response
- 1) Status-Line
  - 1) Status Code and Reason Phrase
- 2) Response Header Fields
7) Entity
- 1) Entity Header Fields
- 2) Entity Body
  - 1) Type
  - 2) Entity Length
8) Connections
- 1) Persistent Connections
- 2) Message Transmission Requirements
9) Method Definitions
- 1) Safe and Idempotent Methods
  - 1) Safe Methods
  - 2) Idempotent Methods
- 2) OPTIONS
- 3) GET
- 4) HEAD
- 5) POST
- 6) PUT
- 7) DELETE
- 8) TRACE
- 9) CONNECT
10) Status Code Definitions
- 1) Informational 1xx
  - 1) Continue
  - 2) Switching Protocols
- 2) Successful 2xx
- 3) Redirection 3xx
- 4) Client Error 4xx
- 5) Server Error 5xx
11) Access Authentication
12) Content Negotiation
- 1) Server-driven Negotiation
- 2) Agent-driven Negotiation
- 3) Transparent 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
  - 1) What is Cacheable
  - 2) What May be Stored by Caches
  - 3) Modifications of the Basic Expiration Mechanism
  - 4) Cache Revalidation and Reload Controls
  - 5) No-Transform Directive
  - 6) Cache Control Extensions
- 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
  - 1) Clockless Origin Server Operation
- 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
  - 1) Byte Ranges
  - 2) Range Retrieval Requests
- 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
- 1) Personal Information
- 2) Attacks Based On File and Path Names
- 3) DNS Spoofing
- 4) Location Headers and Spoofing
- 5) Content-Disposition Issues
- 6) Authentication Credentials and Idle Clients
- 7) Proxies and Caching
  - 1) Denial of Service Attacks on Proxies
16) Acknowledgments
17) References
18) Authors' Addresses
19) Appendices
- 1) Internet Media Type message/http and application/http
- 2) Internet Media Type multipart/byteranges
- 3) Tolerant Applications
- 4) Differences Between HTTP Entities and RFC 2045 Entities
- 5) Additional Features
  - 1) Content-Disposition
- 6) Compatibility with Previous Versions
20) Index
21) Full Copyright Statement
22) Acknowledgement

14.1 Accept

The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.

Accept	= "Accept" ":"
	#( media-range [ accept-params ] )
media-range	= ( "/"
	\| ( type "/" "*" )
	\| ( type "/" subtype )
	) *( ";" parameter )
accept-params	= ";" "q" "=" qvalue *( accept-extension )
accept-extension	= ";" token [ "=" ( token \| quoted-string ) ]

The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The media-range MAY include media type parameters that are applicable to that range.

Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (Section 3.9). The default value is q=1.

Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q".

The example

Accept: audio/*; q=0.2, audio/basic

SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."

If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

A more elaborate example is

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."

Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,

Accept: text/*, text/html, text/html;level=1, */*

have the following precedence:

1) text/html;level=1 2) text/html 3) text/* 4) */*

The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

would cause the following values to be associated:

text/html;level=1	= 1
text/html	= 0.7
text/plain	= 0.3
image/jpeg	= 0.5
text/html;level=2	= 0.4
text/html;level=3	= 0.7

Note: A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.