Re: Issues with header combination text from draft -16

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

But this is not what the spec says (on my reading of it).  If this truly isn't
a MUST NOT (because proxies may violate this rule) then this is what the spec
should say.

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

Good start.

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

Received on Friday, 9 September 2011 13:55:49 UTC