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
