The current behavior is probably explained, at least partially, by https://mrcoles.com/blog/cookies-max-age-vs-expires/. That is, by a desire to be compatible with old Microsoft Internet Explorer browsers and more modern browsers. I have no idea what the preferred trade-off is today vis-a-vis supporting ancient browsers, but any change of this nature requires careful consideration with regard to potentially breaking support for old, but not ancient, HTTP clients.

@amitsaha Based on my understanding, as per RFC 6265 Section 4.1.2.2 and Section 5.3,

• the check for Expires should be done if MaxAge is 0,
• cookie is valid if both MaxAge is 0 and Expires.IsZero() is true.

If a cookie has both the Max-Age and the Expires attribute, the Max-
Age attribute has precedence and controls the expiration date of the
cookie.  If a cookie has neither the Max-Age nor the Expires
attribute, the user agent will retain the cookie until "the current
session is over" (as defined by the user agent).

So, the patch should be at least like these, yes?

-	if !validCookieExpires(c.Expires) {
-		return errors.New("http: invalid Cookie.Expires")
+	if c.MaxAge == 0 && !c.Expires.IsZero() {
+		if !validCookieExpires(c.Expires) {
+			return errors.New("http: invalid Cookie.Expires")
+		}
 	}

@krader1961 I believe the context here is cookie from client side (before it send), not server/browser side.

See the proposal that adds this method: #46370.

It's unfortunate that the minimal documentation is chosen. The commit message adds more context:

net/http: add Cookie.Valid method

The (*http.Cookie).String method used by SetCookie will silently discard
or sanitize any fields it deems invalid, making it difficult to tell
whether a cookie will be sent as expected.

This change introduces a new (*http.Cookie).Valid method which may be
used to check if any cookie fields will be discarded or sanitized prior
to calling (*http.Cookie).String.

The current behavior is probably explained, at least partially, by https://mrcoles.com/blog/cookies-max-age-vs-expires/. That is, by a desire to be compatible with old Microsoft Internet Explorer browsers and more modern browsers. I have no idea what the preferred trade-off is today vis-a-vis supporting ancient browsers, but any change of this nature requires careful consideration with regard to potentially breaking support for old, but not ancient, HTTP clients.

My concern is that the Expires field is currently optional as per the code, and hence, the behavior of Valid() should reflect that. Of course now having learned about what the spec states, I agree with the proposed fix in #52989 (comment)

Also, my current context is when setting it from the server-side.

See the proposal that adds this method: #46370.

It's unfortunate that the minimal documentation is chosen. The commit message adds more context:

net/http: add Cookie.Valid method

The (*http.Cookie).String method used by SetCookie will silently discard
or sanitize any fields it deems invalid, making it difficult to tell
whether a cookie will be sent as expected.

This change introduces a new (*http.Cookie).Valid method which may be
used to check if any cookie fields will be discarded or sanitized prior
to calling (*http.Cookie).String.

That's unfortunate indeed. The method name, Valid() seems to be only useful for figuring out whether any of the fields will be discarded or not, rather than the validity of the cookie. From where I am, still, I can see a good reason for the proposed fix as per: #52989 (comment)

CC @neild

I agree that Cookie.Valid shouldn't complain about a cookie with a zero-valued Expires.

Some automation will likely kick in, but i have created a PR: https://go-review.googlesource.com/c/go/+/338590/ - thanks all for the discussions and feedback.

Change https://go.dev/cl/407654 mentions this issue: net/http: Cookie.Valid() method should allow zero-valued Expires