/cc @bradfitz

If browsers support it, that's a pretty strong argument to change.

But I defer to @nigeltao & @vdobler.

@dprime You can manually handle these types of cookies:
You are right that the convenience functions like net/http.Request.Cookies and net/http.SetCookies will ignore these cookies. But you can read and set them manually from/to net/http.{Request,Response}.Header directly. Unfortunately this requires you to do all the complicated stuff like parsing the Set-Cookie header yourself. Generating a Cookie header is simple (but as you correctly noted you cannot use net/http.Cookie.String)
So manually working with the raw headers will let you "communicate properly with this web server" "without hacking net/http".

I just checked:

• Safari Version 12.0.2 (12606.3.4.1.4) (on Mac),
• Opera Version:57.0.3098.110 (on Mac) and
• Internet Explorer Version: 11.0.9600.19129

allow this type of cookie name name. (With Opera being based on Chromium this was expected.)

@vdobler Ah, of course, fair point. I was forgetting you don't have to use a cookie jar, it's possible to manually handle the Set-Cookie responses and set the outbound Cookie header directly. The default impl of the cookie jar can't handle these names at all, though.

@dprime I might misremember the details but net/http/cookiejar.Jar should be agnostic to the names. I think you can you the default Jar and populate it with SetCookies and retrieve the cookies with Cookies. Of course you loos the automatic integration with the Client, but if you manually parse the Set-Cookie header, you can construct a Cookie, store that in in a Jar with SetCookies and retrieve it back with Cookies. Now create a Cookie header manually from that Cookie.
The Jar would still do the complicated stuff of domain and path matching and expiration.
It is a hack, but it should work.

There's a decent writeup here of the state of cookie names: https://stackoverflow.com/questions/1969232/allowed-characters-in-cookies

Perhaps we should just copy whatever firefox or chromium do?
This is one such spec:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives

I'm afraid of opening a can of worms:
If we accept more characters in a cookie name we have to support them everywhere, i.e. in Set-Cookie headers and in Cookie headers. That is we not only accept such cookies we receive but we would also would allow to send such cookies. As long a Server and Client share the same types this cannot be fixed (easily). And I doubt that we want e.g. net/http.SetCookie to generate formally invalid cookies.

If we are going to "fix" this we probably have to abandon any spec and just accept everything. Treat (Set-)Cookie headers as UTF-8 encoded and allow anything in name and value, maybe even '=' in values. Adding to the mess people do with cookies "because it works in my browser".

I would suggest "won't fix" as not broken.

I would say that's a reasonable way of thinking about it. However "because it works in my browser" here is equivalent to "this is how pretty much 100% of people currently access http services". Your proposed "fix" is obviously too far - the mozilla spec I linked to is pretty much the standard RFC for tokens in http plus a couple of extras and is likely what Chrome et al use as well.

There is no need for this to be a binary situation of perfect spec adherence or utter chaos. There is an accepted, real world, broad usage of the middle ground. The specs and reality disagree here.

@dprime The Mozilla spec you linked (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives) clearly forbids the use of { and } characters in cookie names. You see there is not a real "accepted, real world, broad usage of the middle ground", even Mozilla does not implement their own specs.

Browsers are very lax. If I read the Chromium tests in https://chromium.googlesource.com/chromium/src.git/+/master/net/cookies/parsed_cookie_unittest.cc correctly than Chromium will accept stuff like name=普通話 and ภาษาไทย=value as valid cookies. (While still rejecting such names if set through the API, see: https://chromium.googlesource.com/chromium/src.git/+/master/net/cookies/parsed_cookie.cc#168 )

If you know of any document which describes what you call "accepted, real world, broad usage of the middle ground" I would be happy if you could provide a copy or a link to it. Your "middle ground" is muddy: While all agree that you cannot have \r or \000 and = in a cookie-name the rest is (to my knowledge) not formalized at all: All browsers try to mimic the behavior of older ones even reproducing strange bugs and counterintuitive behaviour .

• If this issue is about allowing the two characters { and } in addition to what is currently allowed then I would vote for "won't fix" as this is just kludge.

• If this issue is about "allow any valid Unicode code point which is not obviously unfit in cookie names" then I'd like to hand back over to @bradfitz and @nigeltao .

• If this issue is about allowing some additional bytes then we first have to decide on which ones. I would see @dprime in charge of providing the set.

Perhaps we should just copy whatever firefox or chromium do?

Can somebody (@dprime ??) figure out what Firefox and Chromium actually do in terms of code (and what they still reject)? You linked to a Mozilla spec, above, but as @vdobler said, if Mozilla (Firefox) accepts { and } as per the original post, Mozilla's code does not implement their own spec.

I did some test how browser (Chrome, Safari, Opera; all on Mac) handle cookies with names containing (or consisting of) formally forbidden characters:

The following octets may be part of a cookie-name in all three browsers:

0x22 """    0x28 "("    0x29 ")"     0x27 "/" 
0x3a ":"    0x3c "<"    0x3e ">"     0x3f "?"
0x5b "["    0x5c "\"    0x5d "]"    
0x7b "{"    0x7d "}"

The cookie name may start with, end with, contain or consist solely of these characters.

All three browser agree on the handling of 0x3d "=": A cookie name may not start with an equal sign if followed by an allowed characters (but a single = as name is okay; very strange).

Handling between browsers differs for these octets:

0x20 " " : Chrome and Opera: cookie-name must not start or end in a space. Safari: cookie-name must not end in space.
0x2c "," : Works on Chrome+Opera, on Safari not if at start or end of name.

Using UTF-8 encoded runes >= U+0080 in a cookie-name works for Chrome but not in Safari.

(None of the three browser allows 0x3b ";" as part of the cookie-name and none allows octets < 0x20.)

If someone wants to test different browser or different platforms I can supply the code used to test it.

I had problems regarding brackets in cookie name. I've created a PR which should fix it golang/net#33. Brackets are commonly used as a simulation of arrays and to handle it I had to split the required header by myself (for now).

As it isn't explicitly mentioned so far, I'll add a reference to RFC 6265, HTTP State Management Mechanism: https://tools.ietf.org/html/rfc6265  IIRC, it isn't symmetric on the production versus parsing of Set-Cookie and Cookie headers. I'd argue that Go's stdlib makes the right thing easy, and the wrong thing possible, and that's good enough. Postel was wrong, and Go's stdlib weakening its RFC compliance yet further is a bad idea: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00#section-1

@RalphCorderoy Thanks for providing the "Postel was wrong" document!

But as explained above: Even if Postel would not have been wrong we simply cannot be lax during accepting cookies and strict while sending: The whole purpose of a cookie is to be roundtripped back and forth between client and server.

I see just two options.

1. Stick to RFC 6265 (what we do now -- at least if you do not look too closely at space characters in cookie-values)
2. Select a set of browsers and implement whatever they agree on.

I'm in favour of 1.

@bkielbasa I do not think that the use of [ and ] in JavaScript code is a strong argument for allowing them: Plain JavaScript code can use whatever works in the browser but if some JavaScript code intends to have the cookies sent back to the server and processed there, the JavaScript code should stick to well formed cookies only.

Go version: 1.20

I just wanted to add that I too have just run into this and it is extremely frustrating. I now have to write a bunch of additional code and error checking to properly handle cookies, basically re-implementing the cookiejar module because it silently ignores any malformed cookie.

While I understand the desire to adhere to specs and do things the "right" way, the fact of the matter is that reality is chaos and I have to write software that handles reality, not just things that adhere to a spec. I can't control what other websites name their cookies, but I still need to store and use them regardless.

There is no way to even know that things are being ignored because the cookiejar doesn't even have a way to propagate errors, which is another pain point entirely.