Bjoern Hoehrmann wrote:
> ...
>> 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.
Correct.
>> + 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.
It's unfortunate, but I think it would be a service to readers of the
spec to make them aware of that exception.
> ...
>> 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
I would consider that a bug; why would you say that the request entity
is too large if you don't know how large it is?
> 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.
Correct.
> ...
Best regards, Julian