Code change:
A recipient SHOULD treat other octets in field content (obs-text) as opaque data. <del> Field values containing control ( ) characters such as CR or LF are invalid; recipients MUST either reject a field value containing control characters, or convert them to SP before processing or forwarding the message. </del> <ins> Field values containing CR or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message.  Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness if they only appear within safe field value contexts (e.g., data not required by HTTP). </ins> Leading and trailing whitespace in raw field values is removed upon field parsing (e.g., field.parsing).  Field definitions where leading

Related discussion:
text: That's what this does; the text above already has that effect. It does raise the question of whether we should add CTL to , however. Thoughts?
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.
We still need to rewrite or remove
draft-ietf-httpbis-semantics-latest currently says: However, when I implemented an HTTP/1.1 parsing library that followed this rule, it turned out to broken in the real world. Specifically, users reported that sites using Google Analytics were setting cookies with values containing the ASCII character , which is a control character (URL). And in my investigations at the time, browsers and popular clients like curl all supported this just fine. It would be great if the next round of RFCs could look into this in more detail and define the production in a way that would be acceptable to e.g. the browsers. In my library we currently reject NUL and exotic whitespace (, , , ), on the grounds that those are high-risk for interop bugs and splitting exploits, but allow all other bytes to pass through, including control characters. I don't know if that's the best solution, but in our experience it's at least closer to being real-world compatible than what the RFC draft currently says.
See . URL is what browsers implement, which is slightly more lenient than what you have there. web-platform-tests has tests for that as well.
Was this bug reported to Google Analytics?
To be clear, at Mozilla we found the same thing on routers and such. It's not an isolated incident.
As with the discussion we’re having on-thread about , is it worth us revisiting the language in this specification when we know that non-conformance is widespread?
No, control characters as a set being disallowed in header fields is a relatively new requirement, whereas HTTP has explicitly forbidden CR-only line breaks since 1993 because that is a well-known security hole. Allowing some of the control characters to pass through is not going to decrease the security of valid implementations, whereas allowing CR will only increase the number of insecure browsers subjecting their own users to cache poisoning attacks.
Hmmm - unless I'm missing something they weren't allowed in RFC 2616 either. What's new are the instructions for recipients how to deal with malformed values.