Re: NEW ISSUE: repeating non-list-type-headers

* Jamie Lokier wrote:
>Proposed text:

I largely disagree with the proposal, the existing text is quite clear
and the proposal needlessly repeats and adds many things, for example:

>Duplicate headers
>=================
>
>1. Duplicate headers means duplicate headers with the same
>   field-name.  Case differences and LWS before the colon MUST be
>   ignored in the comparison.

The specification already says that field-names are case-insensitive,
and white space cannot be part of the field-name (I don't think the
grammar was meant to allow white space preceding the colon either).

>2. Messages MUST NOT have duplicate headers, except as permitted:
>
>      + Headers whose field-value syntax is a comma-separated list.
>
>      + More generally, when explicitly permitted by other
>        specifications and applications, whose syntax is such that
>        concatenating syntactically valid values with "," (with and
>        without surrounding LWS) does not change the interpretation.
>
>      + Headers received and forwarded unmodified by a proxy (except
>        leading and trailing LWS and multi-line formatting changes,
>        and field-name case changes).

I am not sure why you have the latter two items, they seem to extend
when duplicates are allowed, which they should not.

>      + Set-Cookie in a response message, due to historical accident.

It's not clear to me that this needs to be allowed, and if so, it's
unclear to me that this is the only case that needs to be allowed.

>3. An implementation SHOULD NOT reject a message for containing
>   duplicate headers unknown to the implementation.

Why is it necessary to say this?

>4. At the point where specific headers are interpreted during message
>   processing, if duplicates are present and not permitted as
>   described above, the message SHOULD be rejected as malformed.

I disagree with this, for example, Apache will reject requests with
multiple Content-Length headers with Request Entity Too Large, not
Bad Request; further, there is no reason that I can see why servers
should handle "X: a\nX: b" differently from "X: a,b" if neither is
allowed.

>5. An implementation MAY reject the message earlier using a list of
>   headers for which duplicates are not permitted (e.g., at least
>   those defined in this specification whose syntax is not a
>   comma-separated list).

They already may "reject" them as they see fit, I see no need to re-
peat this here.

>6. The meaning of duplicate headers whose field-value syntax is a
>   comma-separated list, provided the individual values satisfy that
>   syntax, is equivalent to concatening the elements of each list,
>   preserving the order.  The transformation of section 7 gives the
>   same result.  Implementations MUST respect this equivalence.

I am not sure what this is trying to say, but it's a lot less clear
than the existing text, especially on which order they should occur
in the combined value.

>7. When interpreting any header, implementations MAY merge duplicates
>   by concatenating the values with "," between them (optionally with
>   LWS), preserving the order.  This is permitted for all headers and
>   independent of syntax.  In practice, some implementations do merge
>   all duplicate headers in this way internally, except for
>   Set-Cookie, and the technique does satisfy this specification.
>   However, see sections 4 and 5 for preferred behaviours.

This is already implicit.

>8. When a proxy forwards particular headers without modification
>   (except leading and trailing LWS and multi-line formatting changes,
>   and field-name case changes), duplicate headers MUST be forwarded
>   separately in their original order.  A proxy may still apply
>   sections 4, 5, 6 and 7 separately to header interpretation, and it
>   may replace duplicate headers with the concatenated form for those
>   headers whose value is modified prior to forwarding.

This does not make sense (if proxy does not modify, then proxy must
not modify); again I do not see what this adds over the existing text.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 21 November 2007 14:14:44 UTC