boost_file_path() function converts undesirable characters in the path to underscores.
For example, we have path 'http://mysite.com/some page'. Filename for this path will be 'cache/mysite.com/some_page'. This file will never be served by htaccess. I think that it is better to return false for files with undesirable characters.

CommentFileSizeAuthor
boost_file_path.patch689 bytesalex s

Comments

abautu’s picture

What i did was to change
$path = preg_replace('@[^/a-z0-9_-]@i', '_', $path);
to
$path = preg_replace('@[^/a-z0-9_-]@i', '+', $path);
so pages with spaces in url will be "seen" by htaccess.

rsvelko’s picture

in another issue we are working on that same line - for another reason - we have non-unicode urls and boost makes our urls in '_'-s .... so we commented this line out and are testing what can go wrong while our urls work well now...

Question: How does the + change things - why does mod_rewrite see the + and not the '_' ?

mikeytown2’s picture

http://en.wikipedia.org/wiki/Query_string#URL_encoding
+ is the same as a space, so boost will work with paths that have spaces in them.

abautu’s picture

From a URL point of view, + is the same as space. However, from a filesystem point of view they are diferent. When boost mod_rewrite rules check to see if a cached file exists (in order to serve it, instead of firing up PHP), the URL is not fully decoded so it contains + instead of spaces. For this reasons, if I the filename contains spaces or underscore signs, than it doesn't match the rewrite rule and it will not be used.

mikeytown2’s picture

Status: Needs review » Closed (duplicate)

Marking this as a dup of #337435: Non unicode in URL changes to ___.html because I won't need this code if the latest patch in that thread does what it's supposed to do. It was a one or the other, and right now It would be nice to have boost support all urls.