Re: Issues with header combination text from draft -16

On 9/9/2011 8:22 AM, Julian Reschke wrote:
> 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.

Right, and #( item ) reflects item, item, item.  #( items ) is a misnomer
by the ABNF, right?  You have a list of item values, not of items values.

>> 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.

Ok, that transition confused me.  So it was never meant to become the
document's canonical format?  No bother, thanks for clarifying!

>> 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?

What I was asking was why they differ from Accept-Charset and
Accept-Language, handling them differently didn't make sense to me
as a server author.  But I'll go back and review once I've resolved
my immediate concerns.

>> 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>)

It solves the problem that no future headers may be combined, because all
future headers MUST NOT be combined.  The existing rule breaks extensibility
of HTTP, particularly with respect to proxying headers not recognized at the
intermediary.

What is the counter proposal to allow future or X headers to be combined in
contrast to the MUST NOT statement, without the server or proxy author
being able to anticipate?  If this were SHOULD NOT, and the proxy author
chose to treat repeated unrecognized headers as combineable, that might not
be optimal but the author would not be wrong.  As the spec stands, all
unrecognized duplicate fields must be rejected by a proxy.

>> Question; does the spec ever suggest that a non-combineable header may not be
>> presented multiple times?
> 
> It does in the text you quoted:

Duh; yes it makes perfect sense on rereading this the 20th time :)

Thank you.

Received on Friday, 9 September 2011 13:43:14 UTC