Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

bradfitz opened this issue Jan 21, 2016 · 1 comment

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

bradfitz opened this issue Jan 21, 2016 · 1 comment


Copy link

@bradfitz bradfitz commented Jan 21, 2016

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:

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

... are illegal now, per

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:

@bradfitz bradfitz self-assigned this Jan 21, 2016
@bradfitz bradfitz added this to the Go1.7 milestone Jan 21, 2016

This comment has been minimized.

Copy link
Contributor Author

@bradfitz bradfitz commented Mar 31, 2016

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.

@bradfitz bradfitz closed this Mar 31, 2016
@golang golang locked and limited conversation to collaborators Mar 31, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.