RFC 9110 section 5.5: `field-content` doesn't match strings of length 2

[bdarnell]

  field-value    = *field-content
  field-content  = field-vchar
                   [ 1*( SP / HTAB / field-vchar ) field-vchar ]

field-content matches a single field-vchar, and it matches a string of 3 or more characters which may contain internal whitespace as long as its first and last characters are field-vchars. However, it does not match a string of exactly two field-vchars. This looks like it is probably an error, although it has no practical effect because field-content is used only within field-value which can match two-character strings as two single-character field-contents. Removing the 1 would fix the error and allow two-character field-contents.

(discovered in tornadoweb/tornado#3481 (comment))

[mnot]

@reschke

[martinthomson]

@bdarnell is right. In both diagnosis and remedy. This is worth an erratum.

[bdarnell]

Thanks! And while I have your attention, can I ask if the field-content rule is semantically meaningful in any way, or if it's just an editorial choice about how to structure the ABNF? I found the nested repetition here surprising, since (with this erratum fixed) there's never any need for a field-value to contain more than one field-content (two concatenated field-contents are a valid field-content). IMHO it would be a little clearer if field-value were defined to contain zero or one field-contents (although I don't think this would be worth an erratum).

FYI the reason I looked so closely at these rules is because I was looking for formal definitions of the comma-separated list rules from section 5.3 and the processing of list-based and singleton fields. field-value = *field-content looks superficially related to this topic.

[reschke]

@bdarnell is right. In both diagnosis and remedy. This is worth an erratum.

Correct. And sorry for missing the conversation first.

Seems this was already incorrect in https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2