Re: Re[2]: Возможно ли удаление кукисов в запросе перед проксированием на бекенд?

[Yura Beznos]

2009/5/13 Илья Винокуров <ilvin at mail.ru>

>
>
> -----Original Message-----
> From: Yura Beznos <nginx at you-ra.info>
> To: nginx-ru at sysoev.ru
> Date: Wed, 13 May 2009 12:25:27 +0400
> Subject: Re: Возможно ли удаление кукисов в запросе перед проксированием на
> бекенд?
>
> > Не совсем понял.
> > Можете пример привести?
> > В моём случае POST запрос короткий(не более 1000 символов).
>
> > > В принципе, если сделать тело запроса доступным через переменную
> > > $request_body, то можно
> > >
> http://sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html#proxy_cache_key
> > > Но тут возникает вопрос с размерам тела, его нужно ограничивать
> разумными
> > > пределами.
>
> Расшифровываю: Предлагается во внутренностях nginx переделывать Ваш POST
> запрос в "GET" с помощью переменной $request_body. Конечно сравнение не
> совсем корректное, но суть примерно та же.
>
> В результате Игорь офигевает - POST запрос может быть длинным, поэтому его
> стоит ограничить 8к символами, как это сделано в апаче для GET запросов. Или
> стоит ввести хеш функцию MD5($request_body), которая будет гарантированно
> конечной длины.
> Кстати, про MD5() и CRC32() функции - очень хочется их поиметь в конфиге,
> чтобы в nginx иметь возможность вычислять адрес бекенда по содержимому
> переменной, например $cookie_email ..
>
> А у меня возникает недоумение - почему Вам не достаточно 8к символов в GET
> запросе и Вы упорно хотите кешировать POST запрос?
>

GET прекрасно подходит, но код уже готовый и он использует POST.
Переписывать пока нет желания, но сделать это придётся(по ряду других
причин).
На время тестирования системы было интересно использовать то что уже есть.

>
> Про 8к символов - эта цифра вбита в апаче по-умолчанию и все, что связано с
> HTTP, старается эту цифру уважать.
>
> С почтением,
>   Илья Винокуров.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090513/c60df940/attachment.html>