httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: mod_cache and Etag headers
Date Tue, 08 Feb 2005 02:05:58 GMT
--On Monday, February 7, 2005 6:45 PM +0100 David Lichteblau 
<david@knowledgetools.de> wrote:

> we are trying to use mod_proxy/mod_cache as a `reverse proxy' in front
> of our webserver.  In our configuration, we would like Apache to cache
> all responses from our server, but revalidate them for every new
> request.  To do that, we are sending Etag headers and force revalidation
> using "Cache-Control: max-age=0,must-revalidate".

First off, what version are you planning to use?  httpd 2.0.53 has a bunch 
of important fixes for the revalidation functionality.  The httpd trunk in 
SVN (2.1.3-dev as of right now) has a lot more fixes that are probably 
going to be important to seeing this work as a whole.

Your patch below is against 2.1.2-alpha, so that partially answers that 
question.  2.1.2-alpha should contains most of the recent fixes, but you 
should try to follow trunk for now.  (Once 2.0.53 is out, I hope to issue 
another 2.1.alpha release soon.)

>   - When a client connects for the first time, Apache asks our server
>     (code 200), caches the response (including the Etag header) and sends
> it     to the server (code 200), caching the Etag header received.
>     (This works!)
>
>   - When a client (which keeps its own cache) connects for the second
>     time, Apache finds the cached response, revalidates with our
>     server, receives code 304 and sends it back to the client.
>
>     (This happens to work, because the client itself sends along
>     "If-None-Match: <our-etag>" in this case.)
>
>   - When a different client (which does not have our Etag in its cache)
>     connects, Apache should find the cached response for the URL,
> revalidate     with our server, receive code 304 from our server and send
>     the cached response to the client (code 200).
>
> The last situation is what does not work -- our server does not receive
> an If-None-Match header from Apache in this case.

Has it passed the age check?  Oh, wait, your server is setting 
'max-age=0,must-revalidate'.  Okay, so, you'd expect to see that every time.

> Questions:
>   0. Is this supposed to work at all?

Yes.  Whether it does or not is up for discussion.  =)

mod_cache has recently undergone a lot of work to make it better, but there 
might be some corner cases that aren't quite right yet.

>   1. Looking briefly at the mod_cache source code, there appear to be
>      cases dealing with this.  In cache_select_url(), info->etag is
>      looked at to decide whether "If-None-Match" should be inserted into
>      the request.
>
>      However, info->etag is null at this point.
>
>      If I hack this check so that the etag header is looked up from the
>      cached response (see patch below), things work better and our
>      server replies with 304.

Hmm.  That shouldn't be necessary.  The recall_headers function should be 
loading this value.

Which cache provider are you using?  mod_disk_cache or mod_mem_cache?  I 
can only attest that mod_disk_cache works - I don't know anything about 
mod_mem_cache.

>      However,
>
>   2. Apache then sends the 304 response along to the client, although the
>      client did not send a conditional request at all and needs the full
>      cached response.
>
>      There is a check in cache_save_filter() ("Were we initially a
>      conditional request?"), but that check is not reached in this
>      situation.

Again, it should be.

Okay, I just tried a reproduction of what I think you are doing and I found 
two obscenely small one-line bugs.  I just committed fixes in r151815 and 
r151816.  Can you please try trunk?  I expect it might work now.  =)

Thanks!  -- justin

Mime
View raw message