Re: issue with "uncacheable" cache revalidations
On Tue, Dec 1, 2015 at 12:15 PM, Graham Leggett wrote: >> I've been looking at an issue where a revalidation >> of a stale cache entry fails because the 304 response >> on the revalidation doesn't contain its own CC or Expires >> but the URL has a query string. This kicks the revalidation >> response out of the cache save filter early and we never >> get to look at the stale handle and update the headers. > > As I recall there is a specific code path for responses that say "we've asked > for revalidation, revalidation was successful but not cacheable. Return > cached data but invalidate it, it is the best we can do". You're right, I missed that when comparing to my snapshot. It's prefixed by the "Hold the phone..." comment. -- Eric Covener cove...@gmail.com
Re: issue with "uncacheable" cache revalidations
On 1 Dec 2015, at 15:50, Eric Covener wrote: > I've been looking at an issue where a revalidation > of a stale cache entry fails because the 304 response > on the revalidation doesn't contain its own CC or Expires > but the URL has a query string. This kicks the revalidation > response out of the cache save filter early and we never > get to look at the stale handle and update the headers. As I recall there is a specific code path for responses that say "we've asked for revalidation, revalidation was successful but not cacheable. Return cached data but invalidate it, it is the best we can do". Regards, Graham --
Re: issue with "uncacheable" cache revalidations
Eric Covener in gmane.comp.apache.devel (Tue, 1 Dec 2015 10:50:56 -0500): >I've been looking at an issue where a revalidation >of a stale cache entry fails because the 304 response >on the revalidation doesn't contain its own CC or Expires >but the URL has a query string. This kicks the revalidation >response out of the cache save filter early and we never >get to look at the stale handle and update the headers. > >This is also one of the FIXME cases where the 304 still leaks >out to a non-conditional request. > >Part of me wants to merge the Expires/CC headers earlier, or >load up the local variables with what we'd end up merged for >Expires and CC. But since it's just two headers, part of me wants >to peek at them earlier but leave them as distinct things being >tracked in that early if/else/ for the various reasons. > >In the same neighborhood, we are missing a httpbis clarification >about not using Expires when we have parsed CC: s-maxage. On >this fork of the problem I looked at, some third-party component >had added a mystery Expires: $longago to the response to >accompany a cookie. Quick remark: in Drupal7 with mod_http2 1.0.8 I got the feeling that I was seeing a lot of 304's. And many URL's in the Drupal-themes have a query string. >I might not come back to it until the new year. Druk, druk, druk ;-) -- Jan
issue with "uncacheable" cache revalidations
I've been looking at an issue where a revalidation of a stale cache entry fails because the 304 response on the revalidation doesn't contain its own CC or Expires but the URL has a query string. This kicks the revalidation response out of the cache save filter early and we never get to look at the stale handle and update the headers. This is also one of the FIXME cases where the 304 still leaks out to a non-conditional request. Part of me wants to merge the Expires/CC headers earlier, or load up the local variables with what we'd end up merged for Expires and CC. But since it's just two headers, part of me wants to peek at them earlier but leave them as distinct things being tracked in that early if/else/ for the various reasons. In the same neighborhood, we are missing a httpbis clarification about not using Expires when we have parsed CC: s-maxage. On this fork of the problem I looked at, some third-party component had added a mystery Expires: $longago to the response to accompany a cookie. Anyone with strong feelings or insight about either of these cases? I might not come back to it until the new year.
