go: net/http: SameSiteDefaultMode adds an incorrect 'Set-Cookie' attribute

Problem

Currently, http.SameSite offers the http.SameSiteDefaultMode option.

This is handled by code here:

https://github.com/golang/go/blob/07ccdeb1927c77ede1d56ac6f1c1871183761ea4/src/net/http/cookie.go#L220-L229

For SameSiteDefaultMode, it adds SameSite (as a bare key, no =, no value) to the cookie.

On older versions of chrome, this results in the cookie being dropped entirely.

The draft specification for same-site makes it clear now that dropping the entire cookie is incorrect, but previously it implied this was correct behavior, so I wouldn’t be surprised if this issue existed elsewhere too.

If the current draft spec is implemented correctly, SameSite would be parsed as an unrecognised value, and would then result in the samesite attribute it being ignored entirely (that is to say, being treated the same as http.SameSite(0) where nothing is added to the Set-Cookie header).

It seems a bit silly to include an option in the http library to generate an invalid cookie attribute which the browser should just ignore.

Possible Solutions

The 2 solutions that make sense to me are the following:

1. Do nothing. We can document this possible issue with SameSiteDefaultMode and recommend not using it at all.
2. Have SameSiteDefaultMode be the same as http.SameSite(0), where no SameSite attribute is included at all (which causes the browser to default to None or Lax, depending on version/browser).

I think option 2 ends up most closely matching what people would expect SameSiteDefaultMode to do. Technically it’s a backwards incompatible change, which is the only reason I think we may wish to go with option 1 instead.