W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: Issues with header combination text from draft -16

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 09 Sep 2011 15:22:47 +0200
Message-ID: <4E6A1327.2030200@gmx.de>
To: "William A. Rowe Jr." <wrowe@rowe-clan.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2011-09-09 15:00, William A. Rowe Jr. wrote:
> Section 3.2 reads in part;
>
>     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)].
>
>
> Issue 1; The example is wrong, it would be i.e., #(value)

As it's just an example, how exactly is it wrong? The point was to show 
just the notation, I think.

> Issue 2; According to Consolidated ABNF grammar Appendicies, this grammar
> appears to be deprecated.  Is this so?  In the body of the spec, we find only...
>
>    Part 1 has one occurrence outside of Section 3.2, in 9.9 1#( item ) for Via.
>
>    Part 3 has four, in 6.1 #( item ) for Accept, in 6.2 1#( item ) for Accept-Charset,
>    in 6.3 #( item ) for Accept-Encoding and in 6.4 1#( item ) for Accept-Language
>
>    Part 5 has one, in 5.4.1 - 1#( item ) for byte-range-set

It's not deprecated. If it was, we wouldn't be using it.

The consolidated ABNFs just show the variant that you get when you 
transform to standard (RFC5234) ABNF.

> Issue 3; Note that Accept and Accept-Encoding #( item ) differ in ABNF from the other
> four 1#( item ) cases, it's not clear to me why this distinction was made.

These two can be empty. Is this what you meant?

> Issue 4; the spec is explicit in using "MUST NOT", and it is impossible for the
> implementer to predict future field names which represent comma separated lists.
> While it may be too late to resolve all cases in the wild, it seems reasonable to
> insist that future headers or X-Foo-List headers with a -List field name suffix
> will represent comma delimited headers subject to 3.2, while all X headers and
> all future headers which are not named with a -List suffix cannot not be combined.

What problem does that solve?

(also note 
<http://www.mnot.net/blog/2011/08/24/distributed_hungarian_notation_doesnt_work>)

> Question; does the spec ever suggest that a non-combineable header may not be
> presented multiple times?

It does in the text you quoted:

"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)]." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-16.html#rfc.section.3.2.p.7>

Best regards, Julian
Received on Friday, 9 September 2011 13:23:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:47 GMT