It turns out in Jetty, when you attach a cookie, it not only adds a cookie to the HTTP response header, it also alters the value of the Expires HTTP header!
((HttpServletResponse)response).addCookie(cookie);
I need Jetty to stop screwing around with the correct/proper expiry settings.
On a side note, Is there a particular/good reason for it to be behaving like this? My guess is that Jetty is assuming that if a cookie has been set, the content is always dynamic, and hence should be set to expired so that it is not cached.
Update: Testing this using Jetty 8.1.8.v20121106
Just took a walk through the Jetty 8 codebase. Here are the situations in the codebase where Expires (as a HTTP Response header) is forced to a value, or removed if present.
That's it for Expires as a HTTP Response Header.
However, since you pointed this out as a part of .addCookie()
, I'd like to point out that there is also a Cookie spec Expires header, as part of the Cookie value string, found in the Set-Cookie logic on a response.
This will force the Cookie Expires header if the Cookie.setMaxAge()
value is 0 or greater. This is done to work around various browser bugs that do not honor Max-Age=
until Expires=
is also provided on the Cookie value.
Default behavior of Cookie:
Cookie.setMaxAge(-1);
will disable both Max-Age=
and Expires=
Cookie.setMaxAge(0);
will result in Expires=00:00:00 UTC on 1 January 1970
(start of unix epoch)Cookie.setMaxAge(60000);
will result in a Expires=
1 minute in the future.Version 1 Cookie behavior (aka Cookie.setVersion(1)
):
Cookie.setMaxAge(-1);
will disable both Max-Age=
and Expires=
Cookie.setMaxAge(0);
will result in Max-Age=0
and Expires=00:00:00 UTC on 1 January 1970
(start of unix epoch)Cookie.setMaxAge(60000);
will result in Max-Age=60000
and a Expires=
1 minute in the future. If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With