Relationship to the ABNF #Rule

[jyasskin]

As @reschke points out in https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0209.html, https://tools.ietf.org/html/rfc7230#section-3.2.2 says:

A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).

draft-ietf-httpbis-header-structure should explicitly override that prohibition for lists, dictionaries, and parameterised lists. It could do this by using the # construct in the ABNF for those types, but because the parsing algorithm in structured headers isn't actually driven by the ABNF, I'm not sure that's the right approach.

The parsing side is already handled by http://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#text.

[reschke]

-1 on "overriding" anything the base spec says.

If you want list semantics, use the matching ABNF notation.

[jyasskin]

To be clear, I have no objection to using the # ABNF notation if that's what folks think is best.

[mnot]

I don't think we should tie requirements for handling of HTTP extensions into what convention is used to define their syntax. Will raise an issue against httpwg/http-core.

[reschke]

Maybe, but the core question is the behavior, not the syntax (handling empty elements, for instance).

[annevk]

Why is empty special? I'd expect

A-SH-That-Takes-A-String: "Hello
a-SH-That-takes-a-string: 
a-sh-that-takes-a-string: World"

to yield Hello,,World. Might be worth adding some explicit examples if they're not already there of course.

[reschke]

Nope. It would yield Hello,World. See https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.7.p.4

[mnot]

I think this can be closed, as the current draft recommends the use of ABNF, and the core issue seems to be heading in the direction of not tying those semantics to the # rule.

Do we need specific text to handle the situation outlined above (with a blank header line) to assure that it's handled correctly? If so please open an issue dedicated to that.

[annevk]

Filed #686 on that, seems useful especially as I suspect that not many implementations get that right.