Re: X-Accel-Redirect и uri escape

[Rommer]

Hello,

Насколько я вижу, все предыдущие попытки ни к чему конструктивному
так и не привели.

Поэтому предлагаю новую опцию safe_redirect on/off.
Если установлена в "on" в http, server или location, откуда
идет proxy_pass, путь в X-Accel-Redirect воспринимает
как escaped uri. По дефолту стоит в off и поведение
парсера не меняет.

On 11/25/13 15:55, Maxim Dounin wrote:
> Hello!
>
> On Mon, Nov 25, 2013 at 05:00:31AM +0300, Роман Шишнев wrote:
>
>> Hello,
>>
>> Обнаружил несколько странное поведение nginx при обработке
>> X-Accel-Redirect от upstream:
>>
>> При появлении знака "?" в имени файла в заголовке, uri обрезается до
>> этого знака, а все остальное складывается в аргументы. Попробовал
>> этот знак заменить на %3F, все стало ещё интереснее - в uri заменяются
>> на стороне nginx все символы "%" на "%25", в итоге выходит что-то вроде
>> "%253F" при передаче на следующий upstream.
>>
>> Полагаю, если в имени файла встретится последовательность "\r\n", этот
>> файл вообще нельзя будет отправить в nginx с помощью X-Accel-Redirect.
>> В явном виде эта последовательность закончит uri в заголовке на себе,
>> а остаток имени будет следующим зоголовком, а в виде %0D%0A будет
>> превращена в %250D%250A.
>>
>> В первом случае файл "aaa\r\nRefresh: 0;url=login" отправит клиента
>> по другому адресу, а во втором случае комбинацию никакой upstream не
>> разберет.
>>
>> Вопрос как сейчас передавать в nginx с помощью X-Accel-Redirect
>> файлы в имени которых есть спец-символы?
>>
>> Может стоит сделать отдельную опцию (что-нибудь в духе
>> safe_redirect on/off) при включении которой nginx не будет
>> дополнительно escape'ать uri в X-Accel-Redirect?
>
> Сейчас nginx полагает, что в X-Accel-Redirect передаётся
> незакодированный URI.  Есть мнение, что это неправильно (в
> частности потому, что файл с "?" в имени отправить нельзя), и
> надо изменить логику так, чтобы передавался закодированный URI.
>
> Где-то тут про это есть чуть больше подробностей, а также ссылки
> на предыдущие попытки решить проблему:
>
> http://trac.nginx.org/nginx/ticket/316
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nginx-1.4.4-safe_redirect.patch
Type: text/x-patch
Size: 3809 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20131125/33c542a3/attachment.bin>