|
||||||||||||||||
|
||||||||||||||||
|
| |||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
|
 |
| |
|
| |
| |
|
|
|
|
|
АРХИВ :: nginx-ru |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Странное поведение http_rewrite _module
Я уже писал сюда про эту проблему, но дело было перед НГ и формулировка подкачала :) Постараюсь пояснить подробней в чем дело. Вот правило: rewrite ^/download/([^/]+)/(.+)/$ /index.php/download/?hash=$1&filename=$2 last;
/download/b7050cd8740a51db29c7bef9a81c74b970cabca3/19%20Thr3shold%20%26%20Detune%20-%20Shapeshifter%20(Epic%20Mix).mp3/
На выходе получаем: ["QUERY_STRING"]=>
string(120) "hash=b7050cd8740a51db29c7bef9a81c74b970cabca3&filename=19%20Thr3shold%20&%20Detune%20-%20Shapeshifter%20(Epic%20Mix).mp3" То, что было на входе было закодированным амперсантом (%26), на выходе магическим образом опять им стало, только уже без энкода, соотвественно появляется фантомая переменная и имя файла обрезается. Аналогичный результат получаем и когда на входе амперсант незакодирован. Интересно еще то, что пробелы (%20) без всяких проблем оказываются в результирующей строке, чего не скажешь о закодированных символах прямого слеша или апострофа, которые раскодируются в процессе рерайта в оригинальные.
Есть какое то разумное объяснение такому поведению и есть ли способ сохранить оригинальные строки в результирущем url? Заранее благодарен за все ответы. Саша Радостин
_______________________________________________ nginx-ru mailing list nginx-ru@xxxxxxxxx http://nginx.org/mailman/listinfo/nginx-ru
|