Hi, > -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Thursday, June 19, 2014 5:40 PM > > > > I haven't followed all of this discussion, but as for deleting a > > Cookie, I think the problem is that there isn't an explicit > > "Delete-Cookie" header; but instead the server has to send the > > cookie name with a "Expires" flag that is in the past. > > Correct. > > > In this case, I think if the original cookie contained a "Secure" > > and "HttpOnly" flag, then the Set-Cookie header which deletes the > > cookie by setting an "Expire" date in the past also should set the > > "Secure" and "HttpOnly" flags. > > The point is that the "Secure" and "HttpOnly" flags are irrelevant if > the cookie is being expired.
Yes, but what I meant is: >From a human perspective, we know that the "Secure" and "HttpOnly" flags on a >cookie which has an "Expires: 1970" date is irrelevant because it will >immediately expired by the browser if the system clock is set correctly. However, from a technical perspective, it is just a Set-Cookie header that sets a Cookie name and value with some arbitrary "Expires" date; it is not an explicit "Delete-this-cookie" instruction. While the expire date will lead a browser to immediately expire the cookie, it is still a normal Set-Cookie header that will set a cookie on a client with a valid value, but that Set-Cookie header with the "Expires: 1970" parameter did not include the "Secure" and "HttpOnly" flags that were set by the first "Set-Cookie" header, so a client may assume that this cookie is no longer "secure" and "httponly", therefore security scanners might report this. Therefore, in my view, I think it would be better if that Set-Cookie header with "Expires: 1970" would include the same Secure and HttpOnly flags that were used in the first header. > > Although it is unlikely that the client will send back a Cookie > > which expires in 1970, it would be possible if the client's system > > date is set wrong, so IMHO this is not an exact "delete this > > cookie" instruction and therefore the "Expire" Set-Cookie header > > should include the same HttpOnly and Secure flags that were > > included in the original Set-Cookie header. > > I wonder if the spec says something about the minimum date of the > Expires attribute. I'm not going to look it up, but I'll bet that > Expires values prior to start-of-UNIX-epoch are invalid, so basically > timestamp=0l is, by definition, an expire operation regardless of the > client's current clock. I have not found any mentioning of "1970" in RFC6265. It just states in 5.2.1 ("The Expires Attribute"): " If the expiry-time is earlier than the earliest date the user agent can represent, the user agent MAY replace the expiry-time with the earliest representable date." In 5.1.1, it states: " Abort these steps and fail to parse the cookie-date if: (...) the year-value is less than 1601," so I'm not sure that there is a definition of an expire date of 0 ("Thu, 01-Jan-1970 00:00:00 GMT") to be an explicit expire operation. > > Also, when deleting a cookie, I think it might be better to send a > > Set-Cookie header with an empty value, so that the value is > > overwritten by the browser if for some reason the cookie is not yet > > expired. > > > > E.g., instead of Set-Cookie: > > JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu, > > 01-Jan-1970 00:00:10 GMT the server could send: Set-Cookie: > > JSESSIONIDSSO=; Expires=Thu, 01-Jan-1970 00:00:10 GMT > > > > (RFC6265 Section 3.1 shows an example where a cookie is deleted > > this way) > > Seems like a reasonable request, although it should not matter one > bit. Want to create a BZ request for this? Perhaps even a patch? ;) Thanks, I will look into providing patch (when I have some time :) Regards, Konstantin Preißer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org