Subject: Issues with header combination text from draft -16

From: "William A. Rowe Jr." <[email-masked]>
Date: Fri, 09 Sep 2011 08:00:35 -0500

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)

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

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.

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.

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Sep 2011 15:22:47 +0200

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

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

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

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

> 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

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Fri, 09 Sep 2011 08:38:59 -0500

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

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

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

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

> It does in the text you quoted:

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

Thank you.

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Fri, 09 Sep 2011 08:42:08 -0500

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.

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.

Thank you.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Sep 2011 15:50:20 +0200

> by the ABNF, right?  You have a list of item values, not of items values.

Ack.

> ...

Probably for historic reasons.

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

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)

> contrast to the MUST NOT statement, without the server or proxy author

Not sure. Does my reply above answer this?

Best regards, Julian

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Fri, 09 Sep 2011 08:54:42 -0500

On 9/9/2011 8:50 AM, Julian Reschke wrote:
>>> (also
>>> note<http://www.mnot.net/blog/2011/08/24/distributed_hungarian_notation_doesnt_work>)
>>
> 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

Good start.