httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
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" <minfrin@sharp.fm> 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
format:

. 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+
		HeaderValue+URI
		. 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

Mime
View raw message