When a query string contains a non-ASCII like a german umlaut (äöüÄÖÜß), which is very common, a request like
http://yourdomain.com/search?qry=mühle (which translates to "mill") results in a 404.

Boost tries to deliver the file:

cache/normal/yourdomain.com/search_qry=mühle.html

leading to a "file not found" recorded in watchdog.

In fact the cached html-file existing is

cache/normal/yourdomain.com/search_qry=m%C3%BChle.html

I hotfixed the problem by boost-bypassing any URL containing a "%" in my .htaccess. This is the condition:

RewriteCond %{QUERY_STRING} (.*)(%+)

I'd be happy, if you guys could fix this, so I can remove this condition and URLs containing umlauts can be delivered from cache too.

Thank you!!

Comments

Anonymous’s picture

Anonymous (not verified) commented

I do think this is worth investigating, do you know the basis of the web server's distribution ? it is just that we have arabic, russian and french sites all successfully running boost with the strangest of characters in the URL's so an umlaut does appear rather surprising. Knowledge of the versions of apache and PHP would also be appreciated.

Anonymous’s picture

Anonymous (not verified) commented

Thank you for your response Philip!

This is, what phpinfo tells me.

System: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u1 x86_64
PHP Version: 5.4.4-14+deb7u12
Server API: FPM/FastCGI

There is no Apache mod_php in place, rather than PHP FPM.

I'm afraid I have no information about the used Apache Version.

lazly’s picture

lazly commented

I confirm it. My URL is: /kereses?mire=padlizsán (padlizsán meaning egg plant).
The boost fine store the file: kereses_mire\=padlizs%C3%A1n.html
But after the mod_rewrite cant find it, Boost is bypassing.
If I rename the file it's works fine:
cp kereses_mire\=padlizs%C3%A1n.html kereses_mire\=padlizsán.html

Anybody has any idea? :/ Thanks!