W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 09 Jan 2013 18:22:59 +0100
Message-ID: <50EDA773.9080506@gmx.de>
To: Piotr Dobrogost <p@ietf.dobrogost.net>
CC: ietf-http-wg <ietf-http-wg@w3.org>
On 2013-01-09 18:05, Piotr Dobrogost wrote:
> On Wed, Jan 9, 2013 at 5:38 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> On 2013-01-09 17:29, Zhong Yu wrote:
>>> 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
>> also means that just "pairing" double quotes is not sufficient.
> I'm not sure I follow - I'll try to rephrase it. In the past entity
> tags were specified as using quoted-string ABNF production but because
> existing implementations did not implemented this grammar production
> fully (they did not handle backslash as they should) you removed this
> production from specs. The outcome is that "standard" parser which
> parses quoted-string ABNF production can't parse entity tags anymore.

It won't parse entity tags that contain a backslash. We made that change 
because we believe that it reflects would current software actually 
does. And as entity tags are always minted by the server, there really 
shouldn't be a case where the client reformats the entity tag at all.

> Does it mean that If-Match header field's value does no longer is in
> the form of comma-separated list [i.e., #(values)] thus there can't be
> multiple If-Match header fields?

No. Why don't you just look it up? -> 

>>> 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.
> This leads to some questions:
> What are the requirements on parser of conforming user agent in regard
> to parsing header fields' values? Is it required to parse header
> fields' values of all registered header fields? Is it required to
> parse header fields' values for header fields which it handles? Is it
> required to parse quoted-string values?

I don't understand. Why (and how) would you "parse" field values that 
you don't know? To "parse", you need an ABNF, no?

Best regards, Julian
Received on Wednesday, 9 January 2013 17:23:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC