W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: #231: Considerations for new headers

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 30 Jun 2011 10:58:33 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis Group <ietf-http-wg@w3.org>
Message-ID: <20110630085833.GD27687@1wt.eu>
On Thu, Jun 30, 2011 at 05:42:14PM +1000, Mark Nottingham wrote:
> On 30/06/2011, at 5:38 PM, Julian Reschke wrote:
> > 
> > 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 (<http://tools.ietf.org/html/rfc2616#section-3.6>).
> Yes, I'm still figuring out how to best illustrate the point I'm trying to make; revised proposal soon.
> > Indeed, we should encourage authors of new header fields to re-use existing ABNF constructs, so that recipients can re-use parser components.
> Yep; that's already an issue <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/266>.

It's not only a matter of re-using existing parser components, but also to
allow participants to adopt consistent behaviour. For instance, the comma
can be used to fold a list of similar headers which are defined as a list.
New headers might be added that will be defined as lists but unknown from
existing components, which might fold them for consistent processing. This
is problematic with some headers that adopt a date format where the comma
is not a list delimitor.

I'm already facing this issue in haproxy. ACLs make it possible to filter
on a header contents. It can iterate over all of a header's values, whether
they're delimited by commas or all on their own line. A date header will be
seen as two occurrences of partial dates due to the comma.

Also I remember that Apache's mod_proxy folds any multiple headers into a
single list, thus if you send two "Date" headers with both parts, it will
rebuild a properly formatted "Date" header.

I suspect that there are not *that* many different behaviours right now
for existing headers. Maybe we could propose a universal syntax that is
recommended to respect for future headers, and document known exceptions ?
After all, if only 3-4 exceptions are identified, it might be worth hard-
coding them in many products.

Received on Thursday, 30 June 2011 08:59:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC