Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Field validity and field names containing token delimiters #902

Closed
royfielding opened this issue Aug 17, 2021 · 0 comments · Fixed by #936
Closed

Field validity and field names containing token delimiters #902

royfielding opened this issue Aug 17, 2021 · 0 comments · Fixed by #936

Comments

@royfielding
Copy link
Member

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.

martinthomson added a commit to martinthomson/http2v2 that referenced this issue Aug 23, 2021
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 fix httpwg#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.

Closes httpwg#902.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant