httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Possible new cache architecture
Date Wed, 03 May 2006 20:46:04 GMT
Gonzalo Arana wrote:

> again, I am in the dark: why do cache request headers may need to be
> replaced or edited in the same entity?

It's a requirement of the HTTP/1.1 spec.

HTTP requests can be conditional, in other words a browser (or a proxy) 
can ask a server "give me this URL, but only if it has changed from my 
cached copy".

If the server thinks that the file has changed (or Cache-Control: 
no-cache was specified), then the server will send a full response back 
headers + body, and the browser/proxy replaces it's cached copy with the 
new headers+body.

If the server thinks that the file is the same, ie it didn't change, the 
server sends back the magic code "304 Not Modified", and just the 
headers - without any body. These new headers must replace the existing 
headers in the browser/proxy's cached entry, making the cached entry 
"fresh" again. And here lies the problem.

Doing the request this way means you don't have to ask the backend "is 
my cached copy still fresh?", get an answer back "No", and then send a 
second request saying "ok then, give me the new data" - you can 
implement caching in one request.

The catch is when the server sent "304 Not Modified" - you need to 
update your cache to say "yep, my cached entry is still fresh", ie 
update the headers, without touching the body, which hasn't changed.

> That's why I suggested a dedicated process/thread for cache
> administration, which is not a good idea if too many lookups are
> issued to this process on each request received.

mod_cache definitely needs cache admin, currently it's implemented as an 
external program that is called via cron, which doesn't help if you're 
on a box without cron. Cache cleaning can be done either when a 
connection is complete in the existing process (which may be simpler to 
implement, but it runs after every connection), or it can be done as you 
suggest, where a dedicated thread/process handles this independently.

I think in the long run, a dedicated process is the way to go.


View raw message