https://issues.apache.org/bugzilla/show_bug.cgi?id=45341
--- Comment #12 from Graham Leggett <[email protected]> 2010-09-27 05:59:52 EDT --- It seems this behaviour is triggered when a 304 Not Modified response arrives that contains headers to say that the response isn't cacheable according to the RFC rules. The cacheability check of the response kicks in, says "this (304) is not cacheable, just pass this response through as is", and that's how the 304 gets out. This situation could arise if the origin server has in the mean time changed its mind about whether something is cachable (it was cacheable in the past, now it isn't), or if a broken origin server declares that 2xx responses are cacheable but 304 responses aren't (a contradiction in terms). Neither of these two happen often, which is probably why this problem is so rare in the wild. Given that it isn't practical to restart the request again, it is probably a sensible compromise to pretend we couldn't connect to the backend at all, and return cached content for this request marked with a Warning to say the content is stale (which is what we are allowed to do as per RFC2616), and then we delete this URL from the cache, respecting the headers on the 304. In the case where "s-maxage" or "must-revalidate" has been specified, and we can't return a warning, we delete the URL from the cache, and then could potentially return a redirect back to ourselves, in the process asking the client to try again. Will need to double check this logic against RFC2616. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
