I made a lot of test with apache 2.0.48 compiled on HP-UX 11.00 and with the Apache included in MandrakeLinux 9.1. When I do a GET and obtain a 200 in the reply there are the cache headers, but when the reply is 304 there is no way have theese headers. So when the browser's cache expires, the expire-date is not updated more. For each page I obtain a 304 for each element for ever... Example: the request: GET /test.html HTTP/1.1 Accept: */* Accept-Language: it Accept-Encoding: gzip, deflate If-modified-since: Thu, 20 Nov 2003 11:54:42 GMT If-None-Match: "12a-a0006480" User-Agent: Mozilla/4.0 (compatible; MSIE 6.0) Host: 10.254.3.20 Connection: Keep-Alive the 304 (expire-date is not updated): HTTP/1.1 304 Not Modified Date: Fri, 21 Nov 2003 09:40:43 GMT Server: Apache Connection: Keep-Alive Keep-Alive: timeout=10, max=8 ETag: "12a-a0006480" the 200 (the cache is updated): HTTP/1.1 200 OK Date: Fri, 21 Nov 2003 09:40:43 GMT Server: Apache Last-Modified: Thu, 20 Nov 2003 11:54:42 GMT ETag: "12a-a0006480" Accept-Ranges: bytes Content-Length: 298 Cache-Control: max-age=86400 Expires: Sat, 22 Nov 2003 09:40:33 GMT Keep-Alive: timeout=10, max=10 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 Data (298 bytes) I think there is a problem in mod_expires... Thanks Fabio
I found an old issue (http://www.apacheweek.com/issues/96-08-30)... seems to be an old problem: <cut....> Responses can also contain a definite time when the document will expire, in the Expires HTTP header. There are some cases where the expiry time of a document might change, even if the document itself has not changed. So a 304 status message can include an updated expires time, which the browser should use to replace the expires time in it's cached copy of the file. Currently Apache does not send out the expires header on 304 status, which is required by HTTP/1.1. The problem with not sending out the expires header is that the browser still keeps the old expiry time, so it thinks the document has expired straight away. This will be fixed in the next release. <cut....> Is there a work-around? Thanks, Fabio
I am currently working on this problem. There is not currently a workaround that I know of. I know what the problem is (only certain filters are run in the error path and expires is not one of them). I am currently working on a solution to the problem. Thank you for reporting this and for using Apache.
*** Bug 25123 has been marked as a duplicate of this bug. ***
The solution lies somewhere within the following: mod_expires only register with "ap_register_output_filter"... and within "modules/http/http_protocol.c", we do this (flushing the output filter): AP_DECLARE(void) ap_send_error_response(request_rec *r, int recursive_error) { int status = r->status; int idx = ap_index_of_response(status); char *custom_response; const char *location = apr_table_get(r->headers_out, "Location"); /* At this point, we are starting the response over, so we have to reset * this value. */ r->eos_sent = 0; /* and we need to get rid of any RESOURCE filters that might be lurking * around, thinking they are in the middle of the original request */ r->output_filters = r->proto_output_filters;
This PR has been fixed in the 2.1-dev branch and has been suggested for backporting to the 2.0 stable branch. Thank you for using Apache and for submitting this report.
I can't use "-dev" version... I'll wait for the 2.0.49 (I hope). Thank you very much for your work!! Bye