On 13/06/2020 19:20, S V Pavankumar wrote:
> Hi,
> I am checking the RFC6265 as we wanted to switch to the RFC6265 Cookie 
> processor. One thing I have noticed is around, the way cookie expires date is 
> written to the response.
> As per the RFC the date should follow RFC1123 date format 
> https://tools.ietf.org/html/rfc6265#section-4.1.1

The use of "SHOULD" in that requirement allows implementations to
deviate from the requirement with good reason.

Tomcat is using:
"EEE, dd-MMM-yyyy HH:mm:ss z"

The HTTP formats are:
"EEE, dd MMM yyyy HH:mm:ss z"    (preferred)
"EEEEEE, dd-MMM-yy HH:mm:ss zzz" (obsolete)
"EEE MMMM d HH:mm:ss yyyy"       (obsolete)

If you look at the comments in the source code, you will see that the
date format Tomcat is using is the date format defined by the original
(Netscape, version 0) cookie specification.

The reason for this is the historically appalling record browsers have
for implementing the cookie specifications. The expires attribute is
only being added because Microsoft browsers didn't (still don't?)
understand the Max-Age attribute. I don't recall if the original
Netscape format was chosen because the Microsoft browsers required it or
if it was just the result of being cautious.

For some background see:


> Tomcat date is getting started with short wkday then following date2 
> (contains dashes) format instead of date1.  I see both the cookie processors 
> of tomcat are following the same pattern. Can tomcat keep the behavior 
> according to RFC in future updates ?

Changing anything related to cookies has historically broken stuff so I
am very reluctant to do so. Is this behaviour breaking something for
you? If so, what? I'd expect any RFC6265 compliant client to be able to
parse an Expires attribute generated by Tomcat.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to