Re: mod_cache and Etag headers
Hi, Justin Erenkrantz <[EMAIL PROTECTED]> writes: > Okay, please try again. =) I've committed fixes in r152973: these > should go some way to addressing these problems. works fine now! Thank you, David
Re: mod_cache and Etag headers
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> > The cached response _body_ is delivered to the client just fine, but
> > together with the 304 response _header_ just received from the upstream
> > server.
> Try trunk now: r152680 is the relevant commit. Thanks. -- justin
Did that, but the results are still confusing.
| --- modules/cache/mod_cache.c (revision 152679)
| +++ modules/cache/mod_cache.c (revision 152680)
| @@ -532,6 +532,12 @@
| /* Oh, hey. It isn't that stale! Yay! */
| cache->handle = cache->stale_handle;
| info = &cache->handle->cache_obj->info;
| +/* Load in the saved status. */
| +r->status = info->status;
info->status at this point is zero, because file_cache_recall_mydata()
does not initialize it.
But setting it properly does not help either. The client gets the bogus
304 no matter what info->status is at this point.
| +/* The cached response will override our err_headers_out. */
| +apr_table_clear(r->err_headers_out);
| +/* Merge in our headers. */
| +ap_cache_accept_headers(cache->handle, r);
What about r->headers_out here? Does it have to be cleared, too?
It still contains headers which came just in from the upstream server.
ap_cache_accept_headers() updates these headers, but does not replace
them entirely.
(Not that I have much clue which headers are what here, but I get
"Transfer-Encoding: chunked" in the not-chunked-at-all response, so that
must have come through from the upstream server.)
| rv = OK;
| }
| else {
Thanks again for the help,
David
Re: mod_cache and Etag headers
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> 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.
Right now I am looking at trunk, since 2.0.52 did not work.
Of course, it would be very helpful if this could be backported to 2.0
at some point. Looking at the diff between 2.0.52 and 2.0.53, the
latter looks like trunk without your latest commits, so probably does
not work for us yet.
> Which cache provider are you using? mod_disk_cache or mod_mem_cache?
mod_disk_cache
> > 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 for your help! With these commits things work better, but then
something funny happens:
The cached response _body_ is delivered to the client just fine, but
together with the 304 response _header_ just received from the upstream
server.
Unfortunately I am not familiar with the sources and don't know how to
fix this myself right now.
Thanks,
David
mod_cache and Etag headers
Hi,
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".
This mostly works, but does not perform caching the way we would like it
to, because the Etag headers are not sent to our server when mod_cache
tries to revalidate it cache file.
We would like the following to happen:
- 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: " 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.
Questions:
0. Is this supposed to work at all?
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.
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.
Thanks for any help,
David
--- httpd-2.1.2-alpha-orig/modules/cache/cache_storage.c2004-11-27
20:06:48.0 +0100
+++ httpd-2.1.2-alpha/modules/cache/cache_storage.c 2005-02-07
18:14:09.0 +0100
@@ -255,6 +255,8 @@
/* Make response into a conditional */
/* FIXME: What if the request is already conditional? */
+if (info)
+info->etag = apr_table_get(h->resp_hdrs, "etag");
if (info && info->etag) {
/* if we have a cached etag */
cache->stale_headers = apr_table_copy(r->pool,
