It looks like the authcache code intends to not cache 404 errors, and the logic for this is based on the boost module:
http://drupalcode.org/viewvc/drupal/contributions/modules/boost/boost.mo...

However, in authcache.helpers.inc there was an attempt to "flip the logic around" in a way that broke it. The attached patch fixes it so only html 200 response codes are cached (unless explicitly listed to cache) the same as the boost module does it in the above commit. (Note that in the latest version of the boost module the logic in this area has changed considerably since the above linked commit)

CommentFileSizeAuthor
authcache.helpers.inc_.patch733 bytesJeremy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jonah Ellison’s picture

Ah-hah, you found the old Boost code I borrowed. ;)

This logic definitely needs to be updated, though I believe 404s should be safe to cache, unless you can think of a reason otherwise. Drupal core 6 & 7 both cache 404s (and even 403s) and it looks like Boost prevented this due to mod_rewrite limitations (http://drupal.org/node/311988).

Jeremy’s picture

On a client website where we deployed authcache, we have had some pages generate a 404 for anonymous users which then gets cached. The bigger issue is determining why a valid page is intermittently generating a 404 (which may have been a now-resolved memcache configuration issue), but for now the request was to simply not cache 404 pages.

At minimum the comment should be updated to explain what the code is doing, as currently a page is only not cached if it's not explicitly listed for caching AND it's not text/html AND it's not a 200.

puddyglum’s picture

Thanks, I was getting both 404 and 403 pages cached... appears to have resolved it! Thanks!

zacpal-1’s picture

I'm periodically getting valid URL's returned as 404 then being cached that way. Is this patch what'll resolve this problem?

evancooperman’s picture

That's exactly what it should resolve.

simg’s picture

Status: Active » Closed (fixed)