tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Date Thu, 19 Jun 2014 15:40:08 GMT
Hash: SHA256


On 6/18/14, 12:05 PM, Konstantin Prei├čer wrote:
>> -----Original Message----- From: Christopher Schultz
>> [] Sent: Wednesday, June 18,
>> 2014 4:23 PM To: Tomcat Users List Subject: Re: Regarding
>> JSESSIONIDSSO Cookie maintained by tomcat
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> Konstantin,
>> On 6/18/14, 5:34 AM, Konstantin Kolinko wrote:
>>> 2014-06-18 11:57 GMT+04:00 Konstantin Kolinko 
>>> <>:
>>>>> HTTP/1.1 302 Found Set-Cookie: 
>>>>> Expires=Thu, 01-Jan-1970 00:00:10 GMT Pragma: No-cache
>>>>> Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00
>>>>> UTC Set-Cookie: 
>>>>> JSESSIONID=235F4293591E5C72859317ED3294C5A5; Path=/admin; 
>>>>> Secure; HttpOnly Location: https://X.Y.A.B/admin/login.jsp 
>>>>> Content-Length: 0 Date: Tue, 17 Jun 2014 16:21:17 GMT
>>>>> Server: XYZ
>>>> With that value of "Expires" the cookie is actually being 
>>>> cleared, not set.
>>> The 'Secure' flag says that the browser should never send the 
>>> cookie to the server over a non-secure connection.
>>> When the cookie is being cleared, the "Secure" flag is
>>> irrelevant, as the cookie will not be sent back by the
>>> browser.
>> +1
>>> The "HttpOnly" flag says that the cookie should not be
>>> accessible from Javascript code running in the browser. If the
>>> cookie is being deleted, is there a way to access it from
>>> Javascript? I think that there is no such way.
>> +1
>> I think this is a spurious error being flagged by the security 
>> scanner. Adding "HttpOnly" and "Secure" flags to the "expire" 
>> Set-Cookie header is just a waste of bytes because they have no
>> effect whatsoever on what the client does with the cookie (it
>> always deleted it, unless the system clock is set horribly
>> wrong).
> 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.


> 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.

> 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.

> 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? ;)

- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message