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

Re: First reactions to mandatory draft

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 20 Jan 98 13:06:34 PST
Message-Id: <9801202106.AA07704@acetes.pa.dec.com>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: Paul Leach <paulle@microsoft.com>, "'Scott Lawrence'" <lawrence@agranat.com>, Rohit Khare <rohit@bordeaux.ics.uci.edu>, ietf-http-ext@w3.org
    We can't guarantee this as a proxy may change the order of the headers.

To be more precise, the HTTP/1.1 spec says (in section 4.2)

    The order in which header fields with differing field names are
    received is not significant.

which presumably means that this is not something that can be
changed in HTTP/1.X (for all X).

On the other hand, it's not clear to me that an extension-aware
HTTP implementation should be discarding headers as "unrecognized"
before it has parsed them all.  I understand that this somewhat
complicates the parser, but there are other aspects of HTTP
header parsing that require buffering some of the headers, and
I don't see why we shouldn't expect that this is part of the
solution for an extension mechanism.

Consider another, perfectly legal example:

	GET /foo.html HTTP/1.1
	Accept-Language: en;q=0.9
	Host: bar.com
	Accept-Language: fr;q=0.5
	User-Agent: Count Chocula
	Accept-Language: en-us;q=0.7

I don't see how you can properly parse the Accept-Language
field without at least some buffering.  (Not "back-tracking",
but "buffering.")

It is definitely important that we not force implementors to
undergo unnecessary complexity.  At the same time, we should
not warp the protocol design into unnatural forms just to
make possible the simplest imaginable implementation, especially
for optional features of the protocol.

Received on Tuesday, 20 January 1998 16:06:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:07 UTC