Support » Plugin: WP Super Cache » [Plugin: WP Super Cache] still not corrected… bug about unicode-range letters in permalink

  • see: http://wordpress.org/support/topic/262117?replies=9

    once i have looked new code about this fix, now there is other code…
    now i have enabled super cache and see that this still or again (i have not tested versions between these) do not work in the new version.

    function get_current_url_supercache_dir is in wp-cache-phase1.php now.

    i think now may be you donncha have not corrected this because may be this fix (adding urldecode) produces filenames with unicode letters? and such filenames are not supported on many hosts? what happen if not supported… i think just one-byte view of unicode appear… and it anyway do not work… so, why you have not included this fix in official/repository code?

    in new version i think fix is may be same, but surround “$uri” with urldecode:
    $uri = preg_replace('/[ <>\'\"\r\n\t\(\)]/', '', str_replace( '/index.php', '/', str_replace( '..', '', preg_replace("/(\?.*)?$/", '', urldecode($uri) ) ) ) );

Viewing 15 replies - 1 through 15 (of 54 total)
  • Plugin Author Donncha O Caoimh

    (@donncha)

    The main reason for not fixing this is security reasons. When you urldecode $url you can create odd characters and yes, I don’t know what those odd characters will do on different file systems.

    I’d love to get the opinion of a hardened security expert who knows about all this.

    ok

    i said “and it anyway do not work…” . no, it can work, depending on whether apache also will request from system files with same names, producing their names from rewrite rules.

    if use urlencoded file names… hm… urlencoded file names are used when requesting server! so they are original variant of string, not urldecoded. so why urlencoded strings do not work? because of rewrite rules may be… (i thought about this already previous time i explored this, i little remember…)
    may be it is possible to configure rewrite rules to return/output urlencoded strings? (i’ll look documentation.)
    and, alternatively, i know that it is possible to make urlencoder script and use it in rewrite rules, i have made such thing. but this can be considered not fast , if script is php, but it is loaded only once, and also can be used compiled c.

    i said “urlencoded file names are used when requesting server! so they are original variant of string, not urldecoded.” . it’s normal. apache always do so. apache always urldecodes request and so use correct filename. it is correct.

    found:
    http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule :

    ‘B’ (escape backreferences)

    With the B flag, it will instead map to index.php?show=/C%2b%2b

    another way, if first somehow do not work, http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap :

    unescape:
    Translates hex-encodings in the key back to special characters.

    if it do not work, “External Rewriting Program”, i have said about it. with this you can make it more quality (?) – escape according to system, for example, only several characters are not allowed in windows xp, like ? , ” , \ . all others can be unescaped. to move from one type system to other type, can make converter of cached files or just clear cache, clear cache is more reliable, because bad characters can be even not copied correctly. and if % sign is not allowed in file names in system, this way is needed, but it, “%”, had been selected as being supported by most of all or all systems and simple character, as i know.

    and there is another way to think or try out: use alias instead of rewrite! mediawiki uses this way.

    Plugin Author Donncha O Caoimh

    (@donncha)

    The escape backreference parameter looks like it might work. Can you modify your .htaccess and try it?

    It’s not really possible to use aliases. You’d have to add one alias for each url on your site wouldn’t you?

    The other thing the plugin could do is in the “last chance” code in wp-cache-phase1.php use the encoded url to match that on the filesystem. This code normally is the last chance to serve a supercached file to anonymous users in case the .htaccess rules are broken.

    you are sure that B does not work?
    ok, i will try.

    alias gives corresponding file that begin with string given in alias, with same ending, i think.

    i tried B also, it is needed to set to RewriteCond directive also, i think, but this directive do not allow that.

    unfortunately,

    Context: server config, virtual host

    for RewriteMap urlencode int:escape.
    i have tried to write RewriteMap urlencode int:escape in server config and ${urlencode:$1} instead of $1 in htaccess, 4 times, and i have this error:
    [Mon Jul 12 14:17:36 2010] [error] [client 127.0.0.1] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://wp.localhost/

    update:
    ah , it is said :

    You would then be able to use this map in a RewriteRule as follows:

    , may be i cannot use it in rewritecond? or should use other way?

    another bug after i have modified wp-cache-phase1.php : post page is not updated after comment is added. if wp-cache-phase1.php is not modified it maybe works, but do not be cached at all, i have not checked it.

    topic where i have written about i have found this bug that cache does not update and think it is related to this utf-8 permalinks : http://wordpress.org/support/topic/plugin-wp-super-cache-clear-cache-after-post-edit .

    there are many places where i think maybe adding urldecode() is needed in function wp_cache_post_change( $post_id ) { …. } in wp-cache-phase2.php.

    i have remembered/understood while reading mod rewrite docs how to make redirect with urlencode with rewritecond, i will try it tomorrow, if the god wants. … no, i think maybe i have been mistaken/confused…

    i have said:

    alias gives corresponding file that begin with string given in alias, with same ending, i think.

    as i have seen one day, it is so only if location is alias of directory or php file (or other such script), in case of php file location can be gotten with $_SERVER’s varaibles, in case of directory, sublocations become alias for corresponding subdirectories and files in them.

    i said:

    in new version i think fix is may be same, but surround “$uri” with urldecode:
    $uri = preg_replace(‘/[ <>\’\”\r\n\t\(\)]/’, ”, str_replace( ‘/index.php’, ‘/’, str_replace( ‘..’, ”, preg_replace(“/(\?.*)?$/”, ”, urldecode($uri) ) ) ) );

    this fix is not good, incorrect, incomplete, it breaks blog: if comment is added to post with non-latin slug, the post’s cache is not updated, new comment do not show up. So for now do not use this fix, leave the plugin as it was. It works, even it serves from super-cache file. Disadvantages are : 1. its speed is only very little slower than if it is served with “half on” mode. 2. It does not reply with 304 status if the cache is not modified. 3. It does not serve gzipped file.
    So suggestion appear in mind: please make this mode so that it can respond with 304 status and can serve gzipped file, i think it is possible. Even it seems easy, maybe i will try to make it… But … Seems Donncha now makes this mode, of serving supercached file with php, more advanced, may be he is already going to do/make these. Approvement: http://ocaoimh.ie/easy-setup-wp-super-cache/ :

    This version also adds a new method of serving cache files. It uses PHP, but serves supercache files. So, it’s a halfway house between using mod_rewrite (difficult to install for some users), and the legacy caching of WP Cache. That caching will be what is activated for users who use the simplified settings page.

    There is also link to download development version, i will now look at it.

    i have looked it, “// last chance, check if a supercache file exists. Just in case .htaccess rules don’t work on this host” section in wp-cache-phase1.php is not yet modified… this code runs in case of non-latin slugs in super-cache mode.

Viewing 15 replies - 1 through 15 (of 54 total)
  • The topic ‘[Plugin: WP Super Cache] still not corrected… bug about unicode-range letters in permalink’ is closed to new replies.