Change Intent

The intent of this change is to correctly parse folded header field values contained (through HttpHeaders) in HttpRequest and HttpClientResponse.

For example, an HTTP request like:

POST /test HTTP/1.1
Header-A: cat\r
 food\r
Header-B: cat \r <- note space before carriage return
 food\r

Would be parsed like:

// CURRENT BEHAVIOR: 
assert(headers['header-a'] == 'catfood');
assert(headers['header-b'] == 'cat food');
// PROPOSED BEHAVIOR:
assert(headers['header-a'] == 'cat food');
assert(headers['header-b'] == 'cat  food');

Justification

RFC 7230 Section 3.2.4 says:

...replace each received obs-fold with one or more SP octets
prior to interpreting the field value or forwarding the
message downstream.

The amount of interior whitespace in an HTTP header value is not significant according to RFC 2616 2.2:

All linear white space, including folding, has the same semantics as SP

Impact

Header folding was deprecated in RFC 7230 (published in 2014) so this is change is unlikely to have a significant impact.

Code that (against the standard) relies on particular whitespace in folded header values will be broken.

Mitigation

I think that this is unlikely to have significant impact.