On Tue, 2 May 2006 15:40:30 +0200 (SAST)
"Graham Leggett" <[EMAIL PROTECTED]> 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
