Support » Plugins » [Plugin: WP Super Cache] when super cache does not set last modified times and etags?

  • when super cache does not set last modified times and etags?
    i have seen once that it does not set them and even also expires header!
    sometimes i have seen that it set them all.
    it was hard to me to check it that time , because i did not know how to use firefox with other profile and have not installed any other browser. by the way, a blog post about how to use several profiles, even in same time:–manage-multiple-firefox-profiles-231646.php .
    i should to check it without cookies of blog or with clear profile because if they exist super-cache can start wp-cache (which is other).
    but even if it was wp-cache, i think it would be good if it could return only header with 304 “not modified” status without sending content at all.
    i think super-cache must do that, because/when it returns simple files for which apache(,for example, and probably many others) calculate etag itself and uses file’s last-modified time.
    and is there difference of super cache(+wp-cache) behavior when setting expires, etag, last-modified http headers among different types of pages: pages like “about”, month archive pages, post pages, category pages?

Viewing 8 replies - 1 through 8 (of 8 total)
  • i am sorry i have not set “section” to proper line, has left it “installation”, it should be “plugins and hacks”.
    i did not know how to use this forum.

    qdinar – I looked at implementing 304 support last week for wp-cached files but it uses headers that break godaddy blogs (it’s a long story, google for “wp-cache godaddy”) and I don’t need the extra support hassles.

    It’s not possible to set a 304 on supercache files I think because they’re served through a mod_rewrite ruleset.

    If you can find out how to do any of the above reliably across all hosts I will gladly accept patches.

    So, is this part of the problem as it relates to this post. And, if so, why does the original WP-Cache work on one blog?

    now i have found out that super-cached wordpress does not respond 304 “not modified” status only for pages with url-encoded addresses! this is probably a bug of something.


    these work correctly, send last-modified, etag, expires, max-age headers:

    these send none of those 4 headers!:

    i have gone to cache folder to look at cached files and have found that pages with url-encoded addressess are stored double time! one with uppercase letters and one with lowercase letters, for example:
    there are
    is only one.
    but now i have seen that
    is only one. but it also does not send those needed headers.


    donncha, say please what do you think about this. how to make apache mod_rewrite also to send proper headers for caching when urls consist of unicode range letters and are urlencoded?

    “It’s not possible to set a 304 on supercache files I think because they’re served through a mod_rewrite ruleset.”
    i do not agree with this. as i said, mod_rewrite just sends real file like apache sends it with other apache methods of binding http address to file-system address like alias, documentroot.

    but there seems to be a bug of mod_rewrite or of another thing.

    now i have started to write all post addresses with latin letters and also category and tag names! this will make my blog ugly.

    I don’t know how to make mod_rewrite do what you want. If you find out how, I’ll be more than happy to accept a patch. Sorry.

    file-system directory names where are cache files should be written with unicode letters (“монныңтурында”) instead of url-encoded (“%d0%bc%d0%be%d0%bd%d0%bd%d1%8b%d2%a3%d1%82%d1%83%d1%80%d1%8b%d0%bd%d0%b4%d0%b0”).
    if this rule is set:
    RewriteRule ^/(.*)/$ /var/www/$1
    and there are files named
    works (“200” status, empty page if the file is empty)
    does not work (“Not Found The requested URL /Ó™Ó©Ò¯2/ was not found on this server.” message and “404” status).

    i have tried to make a copy of %d0%bc%d0%be%d0%bd%d0%bd%d1%8b%d2%a3%d1%82%d1%83%d1%80%d1%8b%d0%bd%d0%b4%d0%b0 directory in /wp-content/cache/supercache/test.mysite.tld/ and rename it to “монныңтурында” and corresponding(?) page started to open with “304” status.

    i have found how to fix it, with some help of(by?) donncha :

    open: wp-content/mu-plugins/wp-super-cache/wp-cache-phase2.php
    find: function get_current_url_supercache_dir() { …
    find: $uri = preg_replace(‘/[ <>\’\”\r\n\t\(\)]/’, ”, str_replace( ‘/index.php’, ‘/’, str_replace( ‘..’, ”, preg_replace(“/(\?.*)?$/”, ”, $_SERVER[‘REQUEST_URI’] ) ) ) );
    (second line of code of the function)
    instead of
    $_SERVER[‘REQUEST_URI’] .(wrap with urldecode(…).)

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘[Plugin: WP Super Cache] when super cache does not set last modified times and etags?’ is closed to new replies.