Re: #231: Considerations for new headers

On 19/07/2011, at 6:10 AM, Julian Reschke wrote:

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

Yes. Probably just in IANA considerations; no need to actually register it using the template, just have them list it as reserved.


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

Ack.

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

... if you're using list semantics.

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

Ack. Some of this bleeds into the issue re: microsyntax for headers, I think.


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


Great, thanks.


--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 19 July 2011 10:30:07 UTC