Re: Relative ordering of fields in HTTP request

On Wed, 5 Nov 2003, Jeffrey Mogul wrote:

> P.S.: Alex: does your proxy validation suite check for that
> MUST NOT from section 4.2?

Yes; the RFC text[1] is cross-referenced with test cases[2] so you can
see what is covered. The test suite checks for order preservation
under two basic scenarios:

	* a proxy MUST NOT change the order of multiple header
	  field-values with one field-name (8 test cases)

	* a proxy MUST NOT change the order of cached multiple header
	  field-values with one field-name (4 test cases)

The first test clause contains test cases for both requests and
responses. There are implementations that violate some of the above
test cases, IIRC.


Note that HTTP does have a [theoretical] problem in this area. From
RFC 2616 point of view, extension headers are not #value headers.
However, in the specification that defines a given extension header
(RFC X), the header may be declared using a #value construct. This
means that X-aware intermediaries might split the header while
X-unaware intermediaries might reorder or drop some of the splitted
values. This probably means that HTTP extensions must not declare
#value headers, but they do.

The reason for this [theoretical] problem is that HTTP relies on
header definition in some spec to determine header syntax (e.g., "is
it a list?")  instead of having a fixed set of syntax constructs that
can be recognized without knowing the header semantics. This is not
something one can fix today, of course.

Alex.

[1] http://coad.measurement-factory.com/cgi-bin/coad/SpecCgi?spec_id=rfc2616#excerpt/rfc2616/e3cfaf4252ec84762a2b6860fd58b599
[2] http://coad.measurement-factory.com/cgi-bin/coad/GraseIndexCgi?index_ids=test_clause/rfc2616/endHdr-fwd-order,test_clause/rfc2616/endHdr-hit-order

Received on Wednesday, 5 November 2003 14:52:13 UTC