-
Notifications
You must be signed in to change notification settings - Fork 43
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
Restore recipient requirements for invalid characters in field values #783
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I though the proposal was to go back to what RFC723* said - CTL characters are invalid, but do not require them to be rejected or converted.
That's what this does; the text above already has that effect. It does raise the question of whether we should add CTL to |
I believe the proposed text now is somewhat misleading, as it does not mention that CTLs are (and always have been invalid.
No, that would be a breaking change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about this variation?
Co-authored-by: Roy T. Fielding <fielding@gbiv.com>
We still need to rewrite or remove
|
Network congestion or server load httpwg/http-core#724 Remove TRACE requirement on message/http media type (last normative ref to HTTP/1.1) httpwg/http-core#790 Remove unneeded normative references to MESSAGING httpwg/http-core#796 Remove mid-stream trailers httpwg/http-core#792 Move statement about relation between Content-Length and Transfer-Encoding into Messaging editorial h1-messaging semantics httpwg/http-core#747 Restore recipient requirements for invalid characters in field values httpwg/http-core#783
Fixes #683.