W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

An alterntive approach regarding i93: Repeating Single-value headers

From: David Morris <dwm@xpasc.com>
Date: Wed, 2 Jan 2008 19:37:57 -0800 (PST)
cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.33.0801021844500.29660-100000@egate.xpasc.com>

We have a problem because the current RFC somewhat awkwardly requires that
headers not be repeated unless a list value is allowed ... this correlates
with the permission to fold multiple headers and is neat ...

Except the well known cookie headers must be allowed to repeat and can't
be folded because this syntax requirement wasn't understood by the
designers of the cookie mechanism.

There are other headers such as content-length which by definition would
represent a conflict if the values differed. Not list valued and can't be

Still other non list valued headers where repeated headers would simply be
a waste of space ... e.g., Date, User-Agent, ...

We could solve the cookie (set-cookie also?) issue by documenting an
exception, or we could reword the requirements such that:
  a. An implementation which follows the current specification remains
     in conformance
  b. Cookie and other unknown repeating headers will be handled safely

What I propose is that we change the repeating headers requirement such
that repeated headers are allowed. Folding is only allowed for repeated
headers defined with LIST values. The order of repeated header values must
be preserved by proxies. Conflicting values in repeated headers is an
error and should be handled as such. Optionally interpret if possible,
otherwise reject the request/response.

In my mind, this means we can ignore cookies, if we choose, because this
revised wording makes it an error to fold an unknown header. It also
allows flexibility with future extensions by allowing the designers to
include repeated headers if that makes sense.

Dave Morris
Received on Thursday, 3 January 2008 03:38:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC