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

On Wed, Jan 9, 2013 at 11:25 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2013-01-09 18:08, Zhong Yu wrote:
>>
>> 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
>
>
> What we tested is whether servers that send an ETag of "X" will also process
> "\X" and treat it as equivalent. I believe the outcome was that they don't.
>
>
>>      Entity-Tag: "abc\"
>>
>> it'll fail on good clients which are conformant to RFC2616.

Well this is very funny, apparently, it *is* a valid quoted string per RFC2616

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT except <">>
       quoted-pair    = "\" CHAR

so bare backslashes are allowed, e.g. "\" is a valid quoted string.

That got to be a bug in the RFC, isn't it?

The new syntax for entity-tag also allows bare backslashes. If it was
a bug in the old syntax, the new syntax should probably forbid bare
backslashes.

Zhong Yu


> Yes. Do you have information that this happens in practice? ((a) servers
> using backslash in entity tags, and/or (b) clients parsing them as
> quoted-string?)
>
> Best regards, Julian
>

Received on Wednesday, 9 January 2013 19:37:59 UTC