Re: Issues with header combination text from draft -16

On 2011-09-09 15:38, William A. Rowe Jr. wrote:
> 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.

Ack.

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

Probably for historic reasons.

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

The proxy can combine them. If a particular header field that doesn't 
use the list syntax is repeated, the incoming message is broken. The 
proxy will then transform one kind of brokenness into another kind of 
brokenness.

(Maybe we need an example here, or at least more prose; note that we 
also have 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#considerations.for.creating.header.fields> 
-- work in progress)

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

Not sure. Does my reply above answer this?

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

Best regards, Julian

Received on Friday, 9 September 2011 13:50:52 UTC