Add dashes to dd-mmm-yyyy in cookie's expires UTC string about cookies HOT 4 CLOSED

I will need real proof that the dashes are the reason for the issue and not something else, especially since you are not referencing any actual standards and simply the cURL site. The standards come in the form of RFC 6265.

https://tools.ietf.org/html/rfc6265#section-4.1.1

expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>

https://tools.ietf.org/html/rfc2616#section-3.3.1

HTTP applications have historically allowed three different formats
for the representation of date/time stamps:

 Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
 Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 [8](an update to RFC 822 [9]). The second format is in common use, but is based on the obsolete RFC 850 [12] date format and lacks a four-digit year.

You can see the standard supports our format, and even looks the format "Wed, 06-Jul-16 02:19:47 GMT" is invalid, because you need to have the full weekday name, not the abbreviation.

The expires on this module has been working fine in all browsers I have tested for years and years, so I am not inclined to change it, especially when the standards explicitly state that the format we are using is valid and even preferred.

The RFC goes on further to say the following:

HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields. See section 19.3 for further information.

The wording "MUST only generate the RFC 1123 format" is what we do: that is the format without the dashes.

from cookies.

Yeah, I understand.

I just presented the exact chain of events because that's really all I have to go on. To be clear, I don't actually expect you to change anything. There isn't enough information here and you are compliant with the RFCs.

See, the majority of users on my site do not have issues with my far-future expires login cookie. One user last night did have trouble from their laptop on FF38 on Linux (far from an exotic combination).

After receiving this response...

Set-Cookie: __cfduid=xxx; expires=Wed, 06-Jul-16 02:19:47 GMT; path=/; domain=.example.com; HttpOnly
Set-Cookie: sessionId=xxx-xxx-xxx; path=/; expires=Wed, 06 Jul 2016 02:19:47 GMT; httponly

...their browser had a far-future expiring __cfduid cookie yet only an ephemeral sessionId cookie which baffled me. Especially when "throwing in some dashes" really did fix the issue for them.

Yet, speaking with that user some more today, their browser does correctly parse the expiration of this wikipedia cookie which has the same expires format as my cookie above:

Set-Cookie: WMF-Last-Access=07-Jul-2015;Path=/;HttpOnly;Expires=Sat, 08 Aug 2015 12:00:00 GMT

I will close this issue shortly since I've got nothing, but do you have any advice for a kind of gauntlet I can throw at this user that might illuminate an issue if there is one?

from cookies.

I have the same issue in an unrelated project and I found that the RFC2109 specifies that date in the Expires header must be dash separated. See: https://www.ietf.org/rfc/rfc2109.txt
And it turns out some older Browsers have implemented cookies this way.

from cookies.

Hi @Zeikko RFC 2109 is irrelevant. You can see that the RFC we follow here that I mentioned above, RFC 6265, obsoletes (i.e. replaces) RFC 2965. And RFC 2965 obsoletes (i.e. replaces) the RFC 2109 you are referencing. We can only follow one RFC and we follow the current one: RFC 6265.

from cookies.