httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <>
Subject Re: Possible new cache architecture
Date Tue, 02 May 2006 17:06:17 GMT
On Tue, 2 May 2006 15:40:30 +0200 (SAST)
"Graham Leggett" <> wrote:

> On Tue, May 2, 2006 3:24 pm, Brian Akins said:
> >> - the cache says "cool, will send my copy upstream. Oops, where has my
> >> data gone?".
> > So, the cache says, okay must get content the old fashioned way (proxy,
> > filesystem, magic fairies, etc.).
> >
> > Where's the issue?
> To rephrase it, a whole lot of extra code, which has to be written and
> debugged, has to say "oops, ok sorry backend about the If-None-Match, I
> thought I had it cached but I actually didn't, please can I have the full
> file?". Then the backend gives you a response with different headers to
> those you already delivered to the frontend. Oops.

There is not such scenario. I will simulate a request using the disk_cache

. Incoming client requests URI /foo/bar/baz
. Request goes through mod_http_cache, Generate <hash> off of URI
. mod_http_cache ask mod_cache for the data associated with key: <hash>.header
. No data:
	. Fetch from upstream
. Data Fetched:
	. If format #1 (Contains a list of Vary Headers):
		. Use each header name (from .header) with our request
		values (headers_in) to regenerate <hash> using HeaderName+
		. Ask mod_cache for data with key: <hash>.header
			. No data:
				. Fetch from upstream
			. Data:
				. Serve data to client
	. If format #2
		. Serve data to client

Where is the difference ?

> Keeping the code as simple as possible will keep your code bug free, which
> means less time debugging for you, and less time for end users trying to
> figure out what the cause is of their weird symptoms.

We are trying to get it more simple as possible by separating the storage
layer from the protocol layer.

Davi Arnaut
Davi Arnaut

View raw message