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

On Wed, Jan 9, 2013 at 10:38 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2013-01-09 17:29, Zhong Yu wrote:
>>
>> On Wed, Jan 9, 2013 at 5:00 AM, Julian Reschke <julian.reschke@gmx.de>
>> wrote:
>>>
>>> On 2013-01-09 03:22, Zhong Yu wrote:
>>>>
>>>>
>>>> On Tue, Jan 8, 2013 at 6:28 PM, Piotr Dobrogost <p@ietf.dobrogost.net>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi!
>>>>>
>>>>> In
>>>>>
>>>>> http://trac.tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#section-3.2
>>>>> one reads
>>>>>
>>>>> "Multiple header fields with the same field name MUST NOT be sent in a
>>>>>    message unless the entire field value for that header field is
>>>>>    defined as a comma-separated list [i.e., #(values)]."
>>>>>
>>>>> Is the unwritten assumption that each value out of "values" has no
>>>>> unquoted comma?
>>>>
>>>>
>>>>
>>>> Good question. I think it is true for all headers defined in the spec
>>>> that use the #rule; I guess it is intended to be true in general.
>>>
>>>
>>>
>>> It's a good idea to do, but not always the case. Example: "If-Match" and
>>> "If-None-Match". So to separate values in a list production, code needs
>>> to
>>> understand the syntax of the individual values.
>>
>>
>> The commas in entity tags are "quoted", so it's not a problem for a
>> generic parser which pairs quotes.
>>
>>      If-Match: "12,34", W/"56,78"
>
>
> But they do not use the quoted-string ABNF production (anymore). Note that
> that would imply handling of "\" which we found almost nobody does. This

Do you mean if a server responds

    Entity-Tag: "abc\""

most clients will fail to parse it? But if the server changes it to

    Entity-Tag: "abc\"

it'll fail on good clients which are conformant to RFC2616.

Zhong Yu

> also means that just "pairing" double quotes is not sufficient.
>
>
>> The Link header can contain unquoted commas, since comma is legal in URIs
>>
>>      Link: </page,6>; rel="Previous",  </page,8>; rel="Next"
>>
>> fortunately these commas will be surround by <>, no ambiguity there.
>
>
> Yes, but the parser needs to understand the ABNF of the field value in order
> to decide which is which.
>
>
>> The same bis section also specifically mentions the exception to
>> `Set-Cookie` - each cookie must be declared in its own line, because
>> unquoted comma can appear in the line
>>
>>      Set-Cookie: name=value; path=/ab,1; expires=Wed, 09 Jun 2021 10:18:14
>> GMT
>>
>> If we are to put multiple cookies on one line, the comma in the expiry
>> date does not cause ambiguity, but the comma in the path value could
>>
>>      Set-Cookie: n1=v1; path=/ab,1 , n2=v2
>
>
> Yes, Set-Cookie is a mess. That's why we needed that to call out
> specifically.
>
> Best regards, Julian
>

Received on Wednesday, 9 January 2013 17:09:07 UTC