httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonzalo Arana" <>
Subject Re: Possible new cache architecture
Date Wed, 03 May 2006 21:29:29 GMT
On 5/3/06, Graham Leggett <> wrote:
> 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.
> <snip>
> non-modified response headers to conditional requests need to update
> cached response headers.
> </snip>

> <snip>
> we should try to avoid 'dialog' with cache backend.
> </snip>
> 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.

I see the light now :).

Having a single cache_admin proc/thread would make this easier, since
any operation can be presented as atomic, while it may require more
than a single syscall (I know, the goal is avoid full entity
duplication).  Anyway, I guess a good policy is to have 'editable'
content as binary data (i.e., no variable length).  Perhaps this is
not possible anyway :(.

Of course, to avoid a 'dialog' between httpd process and cache_admin,
both cache_admin and httpd must be smart enough.

> > 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.
> <snip>
> I think in the long run, a dedicated process is the way to go.

+1 :).


Gonzalo A. Arana

View raw message