--On Friday, September 24, 2004 11:39 AM -0400 Bill Stoddard
<bill@wstoddard.com> wrote:
> So we're missing all the code to handle RFC 2616 section 13.3. We're not
> violating the RFC but our cache is sure not as efficient as possible.
Put it this way: we were violating the RFC because our Expires handling was
completely broken and our handling of RFC 2616 13.3 was also broken too.
As I indicated in the commit logs, the problem with
cache_conditional_filter is that it's not possible to alter the filter
chain like it was doing. The cache_conditional_filter was trying to serve
or save the response: but neither was possible at that stage. Therefore,
it didn't do anything at all and ended up returning bogus responses to the
client.
If we want to add that functionality, we need to rethink how to handle
caching-proxied-conditional requests. My preliminary thought is:
1) If cache_select_url() determines the cached response is out-of-date, it
can then add the 'If-None-Match' header (and any other headers as required)
to the request.
2) We'll unconditionally add cache_save_filter because we don't have a
usable cached entity.
3) cache_save_filter can then determine if we receive a 304 back by looking
at r->status.
4) If we receive a 304, then cache_save_filter can update the cached
headers and leave the body alone. [We'd have to add a lookup function at
this point so we can identify which provider needs to be updated.]
5) If we did get a 304 *and* the original request was conditional,
cache_save_filter can then remove itself (after updating headers) and get
out of the way.
6) If we did get a 304 *and* the original request was *not* conditional
(somehow we'd have to signal that, not sure how at the moment), then
cache_save_filter can serve the cached body by calling recall_body and then
eating all saved output.
7) If we didn't get a 304 from the origin server, cache_save_filter
continues normally.
What do you think? -- justin
|