It is fairly common to move rewrite rules into the Apache vhosts file. One reason for this might be to perform rewriting early and then use LocationMatch rules to perform various actions. The problem with doing so is that $_GET['q'] will likely get an extra '/' prepended to it. Meaning that for example what used to be 'node/42' is now '/node/42'. This usually causes no problems because in drupal_path_initialize() we first
$_GET['q'] = drupal_get_normal_path(trim($_GET['q'], '/'));
before we do anything with it. the trim() removes any leading slashes. However DRUPAL_BOOTSTRAP_LANGUAGE happens before DRUPAL_BOOTSTRAP_PATH. Here we currently do no such cleanup:
$args = isset($_GET['q']) ? explode('/', $_GET['q']) : array();
$prefix = array_shift($args);
If there is a leading slash this causes big problems because the first element of the array is now empty instead of a language code.
I did some research to see if I could find any notes on why the trim() was added to drupal_path_initialize() in the first place. This code was committed in 2003 with a very vague commit message:
http://drupal.org/cvs?commit=608
So that doesn't help much.
I'll have a patch shortly.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | language-587706-12.patch | 1.94 KB | plach |
| #8 | language-587706-8.patch | 1.94 KB | plach |
| #3 | language-587706-3.patch | 714 bytes | plach |
| #1 | language_trim_slashes.diff | 825 bytes | dalin |
Comments
Comment #1
dalinsimple patch using ltrim()
Comment #2
aaron commentedsubscribe
Comment #3
plachRerolled
Comment #4
plachGreen. I think it's safe to set this RTBC.
Comment #5
plachtagging
Comment #6
webchickGood catch! Committed to HEAD.
Although, upon reflection, is there any other more "central" place we could move that trim() to so we didn't have to do it in both places?
Temporarily marking "needs work" to answer that question; feel free to bump to "fixed" if the answer is no.
Comment #7
plachI thought about this for a while before rerolling the patch: IMO the answer is no because
drupal_path_initialize()is always executed, whilelanguage_initialize()is executed only in multilingual sites; OTOH language initialization happens before path initialization so they can't rely on one another for polishing$_GET['q']: we should have a dedicated phase happening before.Comment #8
plachI gave this a deeper look: the right place for centralizing
$_GET['q']normalization might be http://api.drupal.org/api/function/request_path/7.Let's see if the bot complains.
Comment #10
plach#8: language-587706-8.patch queued for re-testing.
Cannot reproduce any error on my box.
Comment #11
dalinLooks great to me.
Comment #12
plachFixed the above typo:
$_GET['q].Powered by Dreditor.
Comment #13
webchickGreat. Much cleaner. :)
Committed to HEAD.