Re: #231: Considerations for new headers

On 2011-06-29 12:17, Mark Nottingham wrote:
> <>
> Proposal:
> Move p2 sections 3 and 5 (request and response header fields, respectively, into a new section):
> ------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 a field-value like this:
>    Example-Field: uri=""; date="Sat, 4 May 1996"
> 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.
>    * Whether the header field is useful or allowable in trailers [ref to p1].
>    * Whether the header field should be preserved across redirects.
> ...

Sounds good overall.

On second though, I can see why Amos was confused by ";" and ",". We 
should clarify the roles of "," and ";", where the latter is frequently 
used in header fields that use the "parameter" ABNF 

Indeed, we should encourage authors of new header fields to re-use 
existing ABNF constructs, so that recipients can re-use parser components.

Best regards, Julian

Received on Thursday, 30 June 2011 07:38:56 UTC