httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Corcoran" <mcorco...@warpsolutions.com>
Subject RE: mod_cache does not return a 304 Not Modified
Date Fri, 10 Sep 2004 01:23:08 GMT

Ok, I've tried with 2.0.50, 2.0.51-rc2, and also APACHE_2_0_BRANCH.
They all seem to be exhibiting the same miss-handling of a conditional
request.

Here's what I've found out.

The problem seems to be with the If-None-Match condition, or more
specifically, any condition that requires an Etag.

It seems as though, during the execution of mod_cache.c (and
mod_disk_cache.c), the function ap_meets_conditions() (in
http_protocol.c) is called, which **properly** evaluates the request
conditions and returns the correct status code.  The problem is that,
right at the beginning of the function, the Etag value is attempted to
be retrieved from the r->headers_out table, but the value is always NULL
(at least when called from mod_cache.c), which causes later conditional
checks to always fail, and a status of OK to be returned.  The one case
that you can get a HTTP_NOT_MODIFIED status to be returned is if you
specify a (*) as your Etag in the request, e.g. If-None-Match: *

I would love to help out and try to fix this but, after looking at the
code and debugging for quite a bit, I can't seem to find the appropriate
place where the Etag value is supposed to be read in from the ".header"
file into the r->headers_out table.  If anyone wants to point me in the
right direction or have a look themselves, it would be much appreciated.

Best regards,
Michael Corcoran.


-----Original Message-----
From: Justin Erenkrantz [mailto:justin@erenkrantz.com] 
Sent: Wednesday, September 08, 2004 6:14 PM
To: dev@httpd.apache.org
Subject: Re: mod_cache does not return a 304 Not Modified

--On Wednesday, September 8, 2004 2:51 PM -0700 Michael Corcoran
<mcorcoran@warpsolutions.com> wrote:

> I've looked at the code a little bit (Apache 2.0.50), and at first 
> glance, it seems as though proper 304 response handling might not 
> actually be fully implemented yet.  Is that actually the case, or am I
just missing something.

You should try the APACHE_2_0_BRANCH HEAD, the latest CVS snapshots, or
2.0.51 release candidates at: <http://httpd.apache.org/dev/dist/>

2.0.51 (coming soon) will have a bunch of changes to mod_cache that
*may* fix this.  mod_disk_cache doesn't do anything worthwhile in 2.0.50
due to a lot of bugs and brokenness.  -- justin

Mime
View raw message