net/http: remove support for continuation lines in header parsing

[bradfitz]

Apparently HTTP gave up on some old loose parsing rules at some point and got stricter. The spec now says that HTTP field continuation lines (those starting with a space or tab) like this:

http://play.golang.org/p/2MmjLz7eqg

GET / HTTP/1.1
Foo: bar
 and a continuation line
Another: this one without

... are illegal now, per https://tools.ietf.org/html/rfc7230#section-3.2.4:

Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
(Section 8.3.1). A sender MUST NOT generate a message that includes
line folding (i.e., that has any field-value that contains a match to
the obs-fold rule) unless the message is intended for packaging
within the message/http media type.

Likewise in that section, space before colon is disallowed now, which we accept: http://play.golang.org/p/hCA3o7q-tb

[bradfitz]

Actually, on second reading of the spec, we're fine.

It says we must not send it (but we don't, except for perhaps #14048, which we should do for http/1 too), but we're allowed to accept it:

   A server that receives an obs-fold in a request message that is not
   within a message/http container MUST either reject the message by
   sending a 400 (Bad Request), preferably with a representation
   explaining that obsolete line folding is unacceptable, or replace
   each received obs-fold with one or more SP octets prior to
   interpreting the field value or forwarding the message downstream.

So I think we're fine.

We'll track validating transmitted header fields in #14048 or a related bug linked off there.