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