[EMAIL PROTECTED] wrote:
Sander Striker wrote:
[EMAIL PROTECTED] wrote:
[...]
Might as well not do revalidation in that case; actually that would be
better, because the 304's that are returned may not even be correct. The
conditions are replaced with the ones from the cache, remember?
Yes, I remember, but I must admit that I am slightly confused now. When should
we avoid revalidation with the conditionals from the cache?
Well, we shouldn't; it's a workaround for a different bug. The workaround
however
would be to _never_ use the conditionals from the cache.
If the original request does not contain any conditionals? This is what my
patch does
What I am trying to point out is that you can't use the conditionals from the
cache at all if the CACHE_SAVE filter isn't being invoked. You will get a 304
based
on the conditionals from the cache, which may not be correct with respect to
the conditionals from the request.
[..cut..]
I can see the application. Are you up for submitting a patch to the
default handler? :)
I have attached a patch for this. Two comments:
1. I am not very familar with buckets and brigades, so please check closely if
I did it correct (my tests make me think so). If I did something wrong
feedback
is appreciated such that I can do it better next time :-)
2. ap_meets_conditions returns 3 different values: OK, HTTP_PRECONDITION_FAILED
and
HTTP_NOT_MODIFIED. In my patch I assume that in all cases the response should
go down the filter chain.
I'll review your patch. I'll massage it into shape if needed, given your
comments.
Thanks,
Sander
