PDOException with UTF-8 aliases / boost does not cache pages with UTF-8 aliases

Thanks for updating the issue. Could you provide more information about your solution? It might help people who run into the same issue.

Do we need to put a warning in the boost README? (if one day someone writes one)

Not sure if it's the same bug, but if I create an alias with non-ascii (French accents or Cyrillic letters), the page is not cached. (I could not reproduce the SQL error)

From what I understand, the URL parsed in Boost is from request_uri(), but that function does not urldecode() the data, so a request to http://www.bidon.ca/привет becomes http://www.bidon.ca/%D0%BF%D1%80%D0%B8%D0%B2%D0%B5%D1%82, and the alias cannot be found in the database.

See attached patch.

Drupal 6.x-1.x related issue #797136: utf-8 urls are not cached: filenames encoded wrongly.

Another 7.x-1.x related issue: #1398578: Apache has problem with urlencoded query strings in cached file names

I also has this problem. I installed latest dev (7.x-1.x-dev 2012-Feb-14)

My nodes having non-ASCII characters aren't cached by Boost, but non encoded nodes are cached successfully.

@ trante: can you test the patch in #4 ?

@bgm
Thank you for interest. But the patch didn't help.
Still not caching UTF-8 aliased nodes.

#4 shouldn't do much due to the urldecode loop further down on line #420. I believe the problem is somewhere else; it might have to do with the database not being UTF-8?

At line 420, it decodes the url, but stores it in $parts['url_decoded'], and that is barely used.

In my case, e.g. create a page with an alias "testé", I have isolated the issue to the following code:

function boost_transform_url($url = NULL, $b_path = NULL) {
[...]
    // Get the internal path (node/8).
    if (drupal_is_front_page()) {
      $parts['normal_path'] = variable_get('site_frontpage', 'node');
    }
    else {
      $parts['normal_path'] = drupal_get_normal_path($parts['path']); // <- here
    }

In that function, the value of $parts['path'] in my test is "test%C3%A9" (encoded), so Drupal cannot find the path for the page and eventually boost sets $_boost['is_cacheable'] = FALSE; because of that.

However, even if I put a urldecode($parts['path']) for the drupal_get_normal_path(), Boost will generate a cache file for it, but it will be named "test%C3%A9.html". Then Apache cannot find it because mod_rewrite automatically decodes URLs and searches for "testé.html".

My patch in #4 fixes that issue. The only possible caveat with my patch, is that the file name is UTF-8 on the filesystem. Normally, Linux and others should support this fine. I tested successfully with hebrew and cyrillic.

@ imoreno: I'm not sure on the initial bug report though. According to the query, it seems like correct UTF-8, except for the last caracter, %A.. could that be the issue?

Thanks. Committed to 7.x-1.x d9d912a67c73e89dc86b4f9101fa354929ac4982

#4 doesn't fix the URL encoding issue when there are special characters in the query string (as opposed to URL path). See #1398578: Apache has problem with urlencoded query strings in cached file names

Do you have a patch for boost version 6 ? As am having the same problem with arabic characters generated from pathauto.

Thanks Philip, but i can't get what do you mean by "BOOST_SET_FILE_ENCODING"?

Now my problem is that any page with arabic url is not cached at all, no file is created for it.

Now when i changed the value in BOOST_SET_FILE_ENCODING to cp1256 (for arabic), the files are saved but with wrong encodings + not retrieved back correctly, any idea how to fix it?

Noo the files are saved with wrong encoded characters, not arabic

yessssssssss workeddddd thanksssssssssssssssssssssssss :))))))