- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Jan 98 13:06:34 PST
- 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.
-Jeff
Received on Tuesday, 20 January 1998 16:06:55 UTC