You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HTTP has always forbidden token delimiters in field names. It seems very odd that they are not forbidden in HTTP/2, aside from the specific restriction on colon. The token delimiters are DQUOTE and "(),/:;<=>?@[]{}". We really don't want those allowed in a field name because back-end gateways like CGI assume they have been blocked, and it would mean adding an impossible conversion step when forwarding h2 to h1.
Also, it would be easier to read the Field Validity section if it first referenced what is valid for an HTTP field-name, then exclude uppercase because of lowercasing and permit the special-purpose colon for pseudo-fields, and finally list specific requirements on handling invalid characters because the length-delimited protocol elements might be used to carry invalid characters.
Likewise, separating the error handling for field-name from that of field-value is useful because they are two different algorithms that are usually implemented separately.
The text was updated successfully, but these errors were encountered:
This just moves the reference to the canonical definition of what is
valid up to the top of the section. That's the canonical text.
This emphasizes the point that HTTP/2 is placing *additional*
requirements on endpoints with respect to validation.
This does not really fixhttpwg#902 in the sense that it leaves validation of
DQUOTE and friends to the core semantics implementations.
Note that any "MAY" requirement for rejecting a messaging can have the
desired effect on those generating those messages: if an endpoint puts
DQUOTE in a field name, that message will have little hope of being
successfully handled.
Closeshttpwg#902.
HTTP has always forbidden token delimiters in field names. It seems very odd that they are not forbidden in HTTP/2, aside from the specific restriction on colon. The token delimiters are DQUOTE and "(),/:;<=>?@[]{}". We really don't want those allowed in a field name because back-end gateways like CGI assume they have been blocked, and it would mean adding an impossible conversion step when forwarding h2 to h1.
Also, it would be easier to read the Field Validity section if it first referenced what is valid for an HTTP field-name, then exclude uppercase because of lowercasing and permit the special-purpose colon for pseudo-fields, and finally list specific requirements on handling invalid characters because the length-delimited protocol elements might be used to carry invalid characters.
Likewise, separating the error handling for field-name from that of field-value is useful because they are two different algorithms that are usually implemented separately.
The text was updated successfully, but these errors were encountered: