Parse folded HTTP field values according to RFC 7230

[brianquinlan]

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.

[brianquinlan]

@itsjustkevin I think that this is ready for sign off.

[itsjustkevin]

@vsmenon @Hixie @grouma another breaking change request, hot off the presses!

[Hixie]

SGTM, but didn't we just make a change to remove trailing whitespace? Should we also fold inner whitespace since it's not semantically meaningful? Anyway, either way is fine by me.

[grouma]

SGTM.

[brianquinlan]

SGTM, but didn't we just make a change to remove trailing whitespace? Should we also fold inner whitespace since it's not semantically meaningful? Anyway, either way is fine by me.

My intuition, unsupported by any data, is that folding internal whitespace is likely to break things because developers aren't aware that folding is allowed.

[vsmenon]

lgtm