Matt MacDonald - [12/Oct/04 12:52 PM ] Any word on this? I'm setting the Last-Modified date in a downstream Filter and this data is not being persisted by the ResponseWrapper.

Simone Avogadro - [12/Jan/05 06:59 AM ] the client mis-interprets the page content due to missing content-tpye header

Lars Torunski - [26/Jan/05 03:09 PM ] Taken from: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 14.21 Expires The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See section 13.2 for further discussion of the expiration model. The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time. The format is an absolute date and time as defined by HTTP-date in section 3.3.1; it MUST be in RFC 1123 date format: Expires = "Expires" ":" HTTP-date An example of its use is Expires: Thu, 01 Dec 1994 16:00:00 GMT Note: if a response includes a Cache-Control field with the max-       age directive (see section 14.9.3), that directive overrides the       Expires field. HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). To mark a response as "already expired," an origin server sends an Expires date that is equal to the Date header value. (See the rules for expiration calculations in section 13.2.4.) To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. The presence of an Expires header field with a date value of some time in the future on a response that otherwise would by default be non-cacheable indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field (section 14.9).

Lars Torunski - [30/Jan/05 01:16 PM ] The handling of the "Expires" header can be implemented with the EntryRefreshPolicy in the ResponseContent and CacheFilter.

Lars Torunski - [30/Jan/05 01:19 PM ] I try to implement the handling of the header with the changes in release 2.2.

Lars Torunski - [16/Feb/05 04:10 PM ] More to do in CACHE-137

Lars Torunski - [23/Feb/05 01:20 AM ] Some improvements were done in CACHE-83 according to the Expires header. To implement this improvement, I think we need a expires value in CacheEntry.