Subject: Re: #231: Considerations for new headers

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Aug 2011 17:57:12 +0200

On 2011-07-01 07:05, Mark Nottingham wrote:
> Revised proposal:
> ...

+1 - we may want to add more things or tune, but we should get this in.

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/231/231.diff>

The new text would read:

3.  Header Fields

    Header fields are key value pairs that can be used to communicate
    data abou the message, its payload, the target resource, or about the
    connection itself (i.e., control data).  See Section 3.2 of [Part1]
    for a general definition of their syntax.

3.1.  Considerations for Creating Header Fields

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

    The requirements for header field names are defined in Section 4.1 of
    [RFC3864].  Authors of specifications defining 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).

    New header field values typically have their syntax defined using
    ABNF ([RFC5234]), using the extensions defined in Section 1.2.1 of
    [Part1] as necessary, and are usually constrained to the range of
    ASCII characters.  Header fields needing a greater range of
    characters can use an encoding such as the one 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 using the quoted-string ABNF
    production (Section 3.2.3 of [Part1]).

    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 specifications defining new header fields are advised to
    consider documenting:

    o  Whether the field is a single value, or whether it can be a list
       (delimited by commas; see Section 3.2 of [Part1]).

    o  Under what conditions the header field can be used; e.g., only i
       responses or requests, in all messages, only on responses to a
       particular request method.

    o  Whether it's appropriate to list the field-name in the Connection
       header (i.e., if the header is to be hop-by-hop, see Section 9.1
       of [Part1]).

    o  Under what conditions intermediaries are allowed to modify the
       header field's value, insert or delete it.

    o  How the header might interact with caching (see [Part6]).

    o  Whether the header field is useful or allowable in trailers (see
       Section 6.2.1 of [Part1]).

    o  Whether the header field should be preserved across redirects.

Feedback appreciated, Julian

---

From: Karl Dubost <[email-masked]>
Date: Fri, 26 Aug 2011 16:16:25 -0400

Le 29 juin 2011 à 06:17, Mark Nottingham a écrit :
> 3.1 Considerations for Creating Header Fields
[…]

Not sure if it's true, but in case it is. After this 

>  Under no conditions can the "Close" field-name be registered, because it is reserved for use as a connection token.

Should there be a mention discouraging the rewriting of headers to change the behavior of an existing header. 

	"Under no conditions a new header should 
	redefine requirements of an existing 
	header." 

I think about the case of proxies rewriting headers and then changing the behavior of the message. Mark already commented on this thread.
http://stackoverflow.com/questions/4798461/cneonction-and-nncoection-http-headers

Cneonction 
nnCoection

It is still strange to me :) 

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Aug 2011 16:39:00 +0200

> 	redefine requirements of an existing

It appears to me that there are lots of things we *could* say; but may 
not have to.

What do others think?

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Aug 2011 17:08:21 +0200

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/231/231.diff>

...applied (minus some typos) as 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1417>.

Best regards, Julian