Re: #231: Considerations for new headers

On 2011-07-01 07:05, Mark Nottingham wrote:
> 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.

Then we probably should put "Close" into the registry as "reserved 
because of ...".

> 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<">.

Commas are only special if you use the #list syntax. We probably need to 
introduce the concept of header fields than can be repeated first, 
otherwise people will be confused.

> 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"

We should point out that it's a really really bad idea to sue double 
quotes unless you're compatible with quoted-string semantics.

We probably should also mention that single quotes are usually not used 
as quoting character, as they are allowed in tokens.

> 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------
> ...

Otherwise sounds good; I'll try to come up with a new proposal myself...

Best regards, Julian

Received on Monday, 18 July 2011 20:11:30 UTC