UP, благо мне этот вопрос так-же крайне интересен.

2010/1/19 Alexander Radostin <alex.radostin@gmail.com>

> Я уже писал сюда про эту проблему, но дело было перед НГ и формулировка
> подкачала :) Постараюсь пояснить подробней в чем дело.
>
> Вот правило:
> rewrite ^/download/([^/]+)/(.+)/$
> /index.php/download/?hash=$1&filename=$2 last;
>
> Запускаем на вход вот такой url (валидный, строки обработаны заранее
> urlencode):
>
> /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@nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>
>


--
Faithfully yours, Eugenie
ICQ #701217
GTalk ekruglov@gmail.com
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru