mod_rewrite & PHP;$ _SERVER ['REQUEST_URI'] против mod_rewrite - PullRequest
2 голосов
/ 06 июля 2011

Быстрый:

Мне любопытно, если кто-нибудь знает об определенных обстоятельствах, при которых $_SERVER['REQUEST_URI'] будет содержать значение, отличное от $_GET['_uri'], учитывая следующее .htaccess для последнего:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ ?_uri=$1 [L,QSA]

Я использовал последний метод $_GET['_uri'], и хотя я знаю, что mod_rewrite все еще будет необходим, я бы хотел избежать хранения URI в качестве параметра запроса.


Ну, я нашел тот, который раньше не замечал; когда загрузчик приложения, которому mod_rewrite forwards не находится в корневом веб-каталоге, $_SERVER['REQUEST_URI'] содержит родительские каталоги, тогда как $_GET['_uri'] содержит только последний компонент URI. Пример:

Начальная загрузка /subdir/index.php
Запрос http://localhost/subdir/foo/bar/baz/

$_SERVER['REQUEST_URI'] "/subdir/foo/bar/baz/"
$_GET['_uri'] "foo/bar/baz/"

Чтобы повторить результат $_GET['_uri'], решили использовать это:

$prefix = trim(dirname(strtr($_SERVER['PHP_SELF'], '\\', '/')), '/') . '/';
$uri = trim($_SERVER['REQUEST_URI'], '/') . '/';
if(substr($uri, 0, strlen($prefix)) == $prefix){
    $uri = substr($uri, strlen($prefix));
}

Но я не использовал $_SERVER['PHP_SELF'] часто в прошлом, и теперь прочитал, что он несет в себе определенные уязвимости и / или несоответствия с его использованием.

1 Ответ

3 голосов
/ 06 июля 2011
http://example.com/meow?param=value&_uri=hihihi
  • Ожидаемый $_GET['_uri'] результат: meow
  • Фактический результат: hihihi
  • $_SERVER['REQUEST_URI'] значение: /meow?param=value&_uri=hihihi
  • $_SERVER['REDIRECT_URL'] значение: /meow

Все из-за [QSA] флага.

Вместо этого используйте $_SERVER['REQUEST_URI'] и / или $_SERVER['REDIRECT_URL'].

Выше для Apache. На IIS 7.x это может немного отличаться.

...