CHttpRequest - Rewrite rule behaviour change

It seems the rewrite rule:

RewriteRule ^(es|en|zh)/?(.*)    index.php/$2?lang=$1 [QSA,L]

Is not working anymore. It seems to be a behaviour change since Yii 1.0.1. CHttpRequest uses $_SERVER['REQUEST_URI'] now in favour of $_SERVER['PATH_INFO'].

Unfortunately is REQUEST_URI not modified by the rewrite rule, so now Yii tries to find a non-existent controller (es for example). So far I could not find a solution.

Yes, that's the change introduced in 1.0.1. The reason is that PATH_INFO is not always reliable. Could you please post your $_SERVER content and the requested URL?

True, PATH_INFO is not always available. Unfortunately the REQUEST_URI will not reflect changes made by the Rewrite engine.

I use the rewrite rule to get improved SEO results for multilang sites.

Here $_SERVER after RewriteRule (local machine, so no GEOIP available):





    [REDIRECT_STATUS] => 200



    [HTTP_HOST] => testdrive

    [HTTP_USER_AGENT] => Mozilla/5.0 (X11; U; Linux x86_64; nl; rv: Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5 FirePHP/0.2.1

    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

    [HTTP_ACCEPT_LANGUAGE] => nl,en-us;q=0.7,en;q=0.3

    [HTTP_ACCEPT_ENCODING] => gzip,deflate

    [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7

    [HTTP_KEEP_ALIVE] => 300

    [HTTP_CONNECTION] => keep-alive

    [HTTP_COOKIE] => lang=nl; PHPSESSID=5233836e96cae49bd854d4461e7358xs

    [HTTP_CACHE_CONTROL] => max-age=0

    [PATH] => /usr/local/bin:/usr/bin:/bin

    [SERVER_SIGNATURE] => <address>Apache/2.2.9 (Ubuntu) DAV/2 SVN/1.5.1 PHP/5.2.6-2ubuntu4 with Suhosin-Patch Server at sg Port 80</address>

    [SERVER_SOFTWARE] => Apache/2.2.9 (Ubuntu) DAV/2 SVN/1.5.1 PHP/5.2.6-2ubuntu4 with Suhosin-Patch

    [SERVER_NAME] => testdrive

    [SERVER_ADDR] =>

    [SERVER_PORT] => 80

    [REMOTE_ADDR] =>

    [DOCUMENT_ROOT] => /home/web/htdocs/yii/WebRoot/testdrive

    [SERVER_ADMIN] => [no address given]

    [SCRIPT_FILENAME] => /home/web/htdocs/yii/WebRoot/testdrive/index.php

    [REMOTE_PORT] => 60364

    [REDIRECT_QUERY_STRING] => lang=es

    [REDIRECT_URL] => /es




    [QUERY_STRING] => lang=es

    [REQUEST_URI] => /es

    [SCRIPT_NAME] => /index.php

    [PATH_INFO] => /

    [PATH_TRANSLATED] => /home/web/htdocs/yii/WebRoot/testdrive/index.php

    [PHP_SELF] => /index.php/

    [REQUEST_TIME] => 1231756314

    [argv] => Array


            [0] => lang=es


    [argc] => 1


Even REDIRECT_URL is not reflecting any change. Could it be a solution to prevail PATH_INFO if available? Perhaps with a switch in urlManager?

What is the requested URL?

request url is: http://testdrive/es/ (in the above case http://testdrive/es but Apache will add the /)

Rewrite rule makes the QUERY_STRING correctly. In PATH_INFO is the rewritten URI, but not in REQUEST_URI.

Response is: The requested controller "es" does not exist.

Might be solvable with a rule in urlManager, only thing I have to define my existing rules twice, and customize createUrl.

A simple fix is in your index.php, add the following line before running app:


The current implementation (v1.0.1) is close to what ZF is doing, which I think is better than our earlier implementation (v1.0.0). But still, there may be situations like yours occur.

Yes, that works too. Will use that for now.

Current implementation will not allow any rewrite redirection without this workaround unfortunately.

Yes, rewriting rules are really tricky because they could easily turn down the default behavior of frameworks. We will see if there's any other reports about this problem and check if we could provide a better solution.

I'd like to see the built-in support for redirect rules as I think it's quite common to use them for SEO purposes. In some cases it's better to use paths instead of query parameters - search engines like that.

Check this: http://www.yiiframew…uide/topics.url

Ok, if you have a rewrite rule like in the first post, then what would you do without using a workaround (assigning path_info to request_uri)? My point is to have embedded framework support so there is no need in any workarounds.

Yes, I am thinking to add an option to allow using $_SERVER['PATH_INFO']. This depends on how many requests for this feature we receive, though.

I’ve ran inro the exactly same problem. And I vote up for adding the support of &#036;_SERVER['PATH_INFO'] to the framework core.

Agree with that!