Re: #231: Considerations for new headers

Revised proposal:

------8<------
3. Header Fields

HTTP header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, or about the connection itself (i.e., control data).  See [ref to part 1] for a general definition of their syntax.

3.1 Considerations for Creating Header Fields

New header fields are registered using the procedures in [RFC3864]. 

Requirements for header field names are defined in [RFC3864], section 4.1. Authors of new fields are advised to keep the name as short as practical, and not to prefix them with "X-" if they are to be registered (either immediately or in the future). Under no conditions can the "Close" field-name be registered, because it is reserved for use as a connection token.

New HTTP header field values typically have their syntax defined using ABNF [ref] (using the extensions defined in [ref to p1] as necessary), and are usually constrained to the range of ASCII characters. Headers needing a greater range of characters can use an encoding such as that defined in [RFC5987]. 

Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes <">. 

For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like these:

  Example-URI-Field: "http://example.com/a.html,foo", "http://without-a-comma.example.com/"
  Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"

Authors of new header fields are advised to consider documenting:

 * Whether the field is a single value, or whether it can be a list (delimited by commas; see [ref to p1]).
 * Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses to a particular request method.
 * Whether it's appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop [ref to p1]).
 * Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it. 
 * How the header might interact with caching [ref to p6].
 * Whether the header field is useful or allowable in trailers [ref to p1].
 * Whether the header field should be preserved across redirects.

3.2 Request Header Fields

[ as in the current section 3 ]

3.3 Response Header Fields

[ as in the current section 4 ]

------>8------

Received on Friday, 1 July 2011 05:05:53 UTC