field line recombination vs empty field line value

[reschke]

5.2 (https://greenbytes.de/tech/webdav/draft-ietf-httpbis-semantics-latest.html#rfc.section.5.2):

"When a field name is only present once in a section, the combined field value for that field consists of the corresponding field line value. When a field name is repeated within a section, its combined field value consists of the list of corresponding field line values within that section, concatenated in order, with each non-empty field line value separated by a comma."

This seems to be a change from RFC 7230, which says in 3.2.2 (https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.3.2.2):

"A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma."

So there's a difference with respect to empty field line values.

Was this change intentional? In that case it needs to be list as change.

I'm asking because RFC 8941 currently is aligned with RFC 7230.

[royfielding]

It's entirely consistent with the requirements on list value generation (MUST NOT generate empty elements) and parsing (MUST ignore empty elements) in 7230, so no change there.

[reschke]

1. Yes, we do have that sender requirement. But we can't deduce a recipient requirement from that automatically.

2. Are you referring to https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.7.p.4:

Empty elements do not contribute to the count of elements present.

?

That is about the validation of the number of list elements. We even say below:

Then the following are valid values for example-list (not including the double quotes, which are present for delimitation only):

  "foo,bar"
  "foo ,bar,"
  "foo , ,bar,charlie   "

[annevk]

It's observable in esoteric cases as also discussed with structured field values (which is why it says what it does), e.g.,:

Foo: "
Foo:
Foo: "

should be equivalent to

Foo: ", , "

to account for naïvely-combining intermediaries.

[reschke]

My concern with the new text is that it makes it impossible to detect whether the sender violated the MUST-level requirement.

Consider:

foo: 1
foo:
foo: 2

Under RFC 7230 and 8941, the SF parser would receive "1,,2" (plus whitespace) and then fail parsing.

With the new recipient requirement, the parser would receive "1,2" (plus ws) and parse this as a two-element list.

That's why I think this is a new requirement (that would need to be documented as such); but I would prefer to get rid of it.

(unless I'm missing something)

[royfielding]

1. Yes, we do have that sender requirement. But we can't deduce a recipient requirement from that automatically.

"For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements" is a recipient requirement that does exactly that. The only way to "parse and ignore" is to exclude empty list elements.

[reschke]

Well. Under that interpretation, we'll need an erratum for RFC 8941, right?

[mnot]

The "for compatibility..." text that Roy mentions in 7230 is specific to the #rule -- it is not a general requirement for all field recipients.

We should back this change out. It's fine for a field to define how empty list elements should be handled (either by the #rule, by SF, or as a one-off), but it's not something we should generalise.

[reschke]

FWIW, the text was added as part of #557.

[reschke]

In particular, with the current text, these two messages

Foo: x
Foo:
Foo: y

and

Foo: x,,y

...would be treated differently.

(wrt layering: field line combination happens at a lower level than "list" processing, right?)