Re: Multiple header fields with the same field name - unwritten assumption about quoted commas in values?

[Julian Reschke <[e-mail]>]

On 2013-01-15 15:28, Zhong Yu wrote:
> On Tue, Jan 15, 2013 at 6:21 AM, Julian Reschke <[e-mail]> wrote:
>> On 2013-01-15 12:47, Piotr Dobrogost wrote:
>>>
>>> To summarize, from the point of view of http client library (see
>>> https://github.com/kennethreitz/requests/issues/741):
>>>
>>> - The safe approach is to not merge any header fields with the same field
>>> name.
>>
>>
>> Yes.
>>
>>
>>> - If merging, merge only those fields which are known to be safe to
>>> merge ie. those, which can be parsed after merging. Also, if the top
>>> most production in BNF specyfing field's value is #(values) it does
>>> NOT mean the field is safe for merging although this seems to be
>>> implied by the statement in the spec starting with "Multiple header
>>> fields with the same field name MUST NOT be sent (...)"
>>
>>
>> If a spec uses the list production but then doesn't allow proper parsing
>> then that spec is buggy (such as Set-Cookie).
>
> It's good to know whether Set-Cookie is the only exception among
> well-known headers existed before rfc2616?
>
> (Any headers introduced after rfc2616 should follow the rule; no slack for them)

It's the only exception I'm aware of (and, btw, this hasn't changed 
since rfc 2068 or even earlier).

Best regards, Julian