Problem

This issue is not limited to Google servers; my client has the same issue with the majority of HTTP servers.

I use a few frameworks to send HTTP requests to Google. There is only curl, but it applies to all frameworks.

curl -i --http1.1 https://www.google.com

I received two interesting headers that we should discuss. I changed unused values in the headers to "*" to better focus on the problem.

Date: Wed, 25 Jan 2023 13:45:10 GMT
Set-Cookie:**********; expires=Fri, 24-Feb-2023 13:45:10 GMT; ************************

As you can see, we got two different date and time formats from the set-cookie header and the date header.

There is also an HTTP status line, which informs us that the server response is HTTP/1.1.

HTTP/1.1 200 OK

I read rfc 7231 in order to better understand which format is correct. This is what I discovered in the section "7.1.1.1 Date/Time Formats."

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content RFC 7231

7.1.1.1. Date/Time Formats

Content:

Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322].
 HTTP-date    = IMF-fixdate / obs-date
An example of the preferred format is
 Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
Examples of the two obsolete formats are
 Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
 Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
A recipient that parses a timestamp value in an HTTP header field MUST accept all three HTTP-date formats. When a sender generates a header field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format.

My HTTP client supports all three formats, but when I try to parse the Google response, I get an error because Google sends set-cookies with the attribute 'Expires' that do not match any of these formats.

Results

I received datetime text "Fri, 24-Feb-2023 13:45:10 GMT" from the google

However, rfc informed us that our client should only parse three formats.

Sunday, 06-Nov-94 08:49:37 GMT
Sun Nov 6 08:49:37 1994
Sun, 06 Nov 1994 08:49:37 GMT

Nothing from this list does match with google's format.

Is it possible that I misunderstood something or that the RFC is simply ignored?

I tried to find information about the format used by the majority of http servers, but nothing came up.

CodePudding user response：

The date formats described in RFC 7231 (which BTW has been obsoleted by RFC 9110) only apply to the header fields using that specific ABNF - cookies are not in scope.

CodePudding user response：

Cookies are described by RFC 6265, so that is where to look to find the syntax for expires. However, the issue remains as you describe it: the server is using a date format that does not seem to match the required syntax.

I think the answer (as pointed out in a comment by Julian Reschke) can be found in section 5, which says that user agents should be prepared to handle syntax outside the formal specification, for reasons of interoperability.

This section specifies the Cookie and Set-Cookie headers in sufficient detail that a user agent implementing these requirements precisely can interoperate with existing servers (even those that do not conform to the well-behaved profile described in Section 4).

A user agent could enforce more restrictions than those specified herein (e.g., for the sake of improved security); however, experiments have shown that such strictness reduces the likelihood that a user agent will be able to interoperate with existing servers.

Section 5.1.1 then lays out the specific algorithm that should be followed to parse dates:

The user agent MUST use an algorithm equivalent to the following algorithm to parse a cookie-date.

The expires value you're seeing is compatible with that algorithm.

In sum, it appears that service providers do not feel compelled to produce headers that comply with the strict syntax when user agents are compelled to accept a looser syntax anyway.