Whitespace is allowed within Header names, should be an Invalid header

Raising here after reporting in requests: https://github.com/requests/requests/issues/4592#issuecomment-382004884

When receiving a malformed Set-Cookie header containing a CRLF, the \r\n character is incorrectly included in the header value, causing requests to include it in the generated Cookie header.

Expected Result

Per RFC https://tools.ietf.org/html/rfc7230#section-3.2.4, “A user agent that receives an obs-fold in a response message that is not within a message/http container MUST replace each received obs-fold with one or more SP octets prior to interpreting the field value.”

Or, just raise an error on the invalid HTTP header.

Actual Result

An invalid Set-Cookie value was returned containing a CRLF character.

Reproduction Steps

Requests maintainers came up with a quick repro using that library in https://github.com/requests/requests/issues/4592#issuecomment-381857896.

Here’s the bogus cookie (extracted from the raw HTTP text):

Set-Cookie: ___utmvbtouVBFmB=gZg
    XbNOjalT: Lte; path=/; Max-Age=900

Which gives:

Cookie: ___utmvbtouVBFmB=gZg\r\n    XbNOjalT: Lte; <other-cookies>

[nateprewitt]

Went ahead and tested. I can’t get this to work in Requests with the current urllib3 master, but that wasn’t making sense. I made a urllib3-only repro and it appears to be fixed for the newline case. I’ll dig into it on the Requests end and see if we’re botching something.

urllib3 doesn’t however handle the other case I posed in the first test of whitespace between a header name and the colon.

Same section of the RFC:

No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling.

So that should probably still be handled, but I’m not sure if you want to track that here or not.

[halbow]

Hello !

I encountered malformed cookie with CRLF with requests (2.21) and urllib3 (1.24.1) so I guess that the fix hasn’t been pushed to the stable version due to the remaining “whitespace-semicolon” problem ? Tell me if you can use some help for this ! For info in my case, the header/cookie with \r\n is used as a test by some firewall to classify the client and the firewall redirect the client send the malformed cookie back !

Thanks for the work on this library !