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: accept cookies with space in the name #11519

Closed
ailg opened this issue Jul 2, 2015 · 6 comments

Comments

Projects
None yet
6 participants
@ailg
Copy link
Contributor

commented Jul 2, 2015

Hello,

net/http does not allow space in cookie name. That's what the RFC mandates unfortunately broken web applications set cookies with names containing a space.

Repro: http://play.golang.org/p/MhiJ2KKFqA

I see we're already flexible for values, so maybe we can be flexible for names too?
CL: https://go-review.googlesource.com/#/c/11863/

Thanks.

@gopherbot

This comment has been minimized.

Copy link

commented Jul 2, 2015

CL https://golang.org/cl/11863 mentions this issue.

@vdobler

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2015

Dealing with cookies from malformed web applications is always possible by manually processing the {Set,}Cookie header. This is painful as one has to reimplement the functionalities of net/http's cookie handling. But as it is doable there is no fundamental need weaken the standard library.

IMHO there is a qualitative difference between malformed values and malformed names (e.g. almost no programming language allows names with spaces). The malformed values were allowed because such values are very common and work on all major browsers (with appropriate quoting). E.g. not all values are allowed, bytes with the high bit set are considered invalid (even if Firefox handles UTF-8 encoded cookie values very well) because they are not that common in the wwild.

I didn't think it through, but I could imagine that allowing spaces in names could produce parsing ambiguities. So please no.

@ailg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 3, 2015

True, it can be re-implemented locally. In that particular case (Google Bug 22245291) I'm also hoping to get the application fixed.

The malformed values were allowed because such values are very common

Where did we get the data that space in values was very common? can we check if space in name is common as well?
I think it would help us make a informed decision:

  • if it's as common as a space in value, maybe balance in favor of consistency and allow it
  • if it's less common as a space in value, maybe balance in favor of rejecting it

and work on all major browsers

Space in cookie name works with Chrome 43. I also checked, it works in Firefox 38 and IE 11. If following major browsers implementation was an argument in the previous decision, maybe balance in favor of consistency and allow it.

I could imagine that allowing spaces in names could produce parsing ambiguities

Name and value are separated with = so I don't see why space would create an ambiguity but maybe, do you have any example?

There's also the case of spaces at the beginning or end but I think we can just trim, like the major browsers do.

@vdobler

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2015

Where did we get the data that space in values was very common? can we check if space in name is common as well?

This was not a scientific statistic evaluation.

Space in cookie name works with Chrome 43. I also checked, it works in Firefox 38 and IE 11. If following major browsers implementation was an argument in the previous decision, maybe balance in favor of consistency and allow it.

No, this statement is misleading. If any major browsers (and curl) wouldn't be able to handle spaces in cookie values Go probably wouldn't have allowed them. The support in major browsers works just in one direction: "No complete support in browser" ==> "No support in Go" cannot be reverted to state "Major browser support" ==> "Go should support it too."

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 24, 2015

Does anybody want to argue for this with data? Otherwise I'm inclined to close the bug.

@adg

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2015

Please close away.

On 25 September 2015 at 04:13, Brad Fitzpatrick notifications@github.com
wrote:

Does anybody want to argue for this with data? Otherwise I'm inclined to
close the bug.


Reply to this email directly or view it on GitHub
#11519 (comment).

@bradfitz bradfitz closed this Sep 24, 2015

@golang golang locked and limited conversation to collaborators Sep 24, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.