Hi,
> -----Original Message-----
> From: Christopher Schultz [mailto:[email protected]]
> 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: [email protected]
For additional commands, e-mail: [email protected]
