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: https://tomcat.markmail.org/thread/g6sipbofsjossacn > 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
