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

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.

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.

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."

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

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).