httpwg
RFC 9110 section 5.5: `field-content` doesn't match strings of length 2
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 https://github.com/tornadoweb/tornado/issues/3481#issuecomment-2819015146)
@bdarnell is right. In both diagnosis and remedy. This is worth an erratum.
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.
