Re: Работа с кастомными дублирующимися HTTP-заголовками запроса

[Dmitry Ivanov]

Здравствуйте, Александр.

Вы писали 12 ноября 2015 г., 20:06:27:

> Есть клиент, который шлет в HTTP-запросе кастомный заголовок, иногда 
> дублирующийся.

> Например

> X-Custom-Header: value1
> X-Custom-Header: value2

Вы уверены, что использование 2-х одинаковых заголовков как-то
регламентировано в RFC?

Кажется, только первое значение имеет э.. значение. Во всяком случае,
по опыту использования Netscaler в качестве баланисровщика.

-- 
С уважением,
 Dmitry   nginx...@sadok.spb.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Работа с кастомными дублирующимися HTTP-заголовками запроса

[Evgeniy Berdnikov]

On Thu, Nov 12, 2015 at 10:42:47PM +0300, Dmitry Ivanov wrote:
> > X-Custom-Header: value1
> > X-Custom-Header: value2
> 
> Вы уверены, что использование 2-х одинаковых заголовков как-то
> регламентировано в RFC?

 RFC2616:

   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e.,
   #(values)]. It MUST be possible to combine the multiple header
   fields into one "field-name: field-value" pair, without changing
   the semantics of the message, by appending each subsequent
   field-value to the first, each separated by a comma. The order in
   which header fields with the same field-name are received is
   therefore significant to the interpretation of the combined field
   value, and thus a proxy MUST NOT change the order of these field
   values when a message is forwarded.

 Практически это касается Set-Cookie, из-за того что в этом хедере
 может присутствовать expires, значение которого пишется с запятой.
-- 
 Eugene Berdnikov

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re[2]: Работа с кастомными дублирующимися HTTP-заголовками запроса

[Александр Попков]

 Да, не совсем уверен подпадают ли кастомные X-* заголовки под "defined as a 
comma-separated list" но в любом случае вопрос не про соответствие RFC.
Вот есть такая ситуация, и повлиять на этого клиента никак нельзя. Вопрос 
остаётся актуален.

>Четверг, 12 ноября 2015, 23:40 +03:00 от Evgeniy Berdnikov :
>
>On Thu, Nov 12, 2015 at 10:42:47PM +0300, Dmitry Ivanov wrote:
>> > X-Custom-Header: value1
>> > X-Custom-Header: value2
>> 
>> Вы уверены, что использование 2-х одинаковых заголовков как-то
>> регламентировано в RFC?
>
> RFC2616:
>
>   Multiple message-header fields with the same field-name MAY be
>   present in a message if and only if the entire field-value for that
>   header field is defined as a comma-separated list [i.e.,
>   #(values)]. It MUST be possible to combine the multiple header
>   fields into one "field-name: field-value" pair, without changing
>   the semantics of the message, by appending each subsequent
>   field-value to the first, each separated by a comma. The order in
>   which header fields with the same field-name are received is
>   therefore significant to the interpretation of the combined field
>   value, and thus a proxy MUST NOT change the order of these field
>   values when a message is forwarded.
>
> Практически это касается Set-Cookie, из-за того что в этом хедере
> может присутствовать expires, значение которого пишется с запятой.
>-- 
> Eugene Berdnikov
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

real_ip_header $variable

[Den Bozhok]

Доброго дня! Пытаюсь решить своеобразную проблему с определением клиентских адресов.Суть в том, что nginx стоит за амазоновским elb балансировщиком.ELB передает траффик в Nginx через proxy_protocol и все вроде бы хорошо и обычной конфигурации типа: set_real_ip_from 192.168.0.0/24;real_ip_header proxy_protocol; должно хватать. но проблема еще в том, что перед elb балансировщиком может быть qrator или его аналог, соответственно нам нужно достать информацию об адресе клиента уже основываясь не исходящий ip адрес запроса,а на заголовок X-Forwarded-For. т.е. в идеале работала бы такая схема: geo $proxy_protocol $real_ip_header {default "proxy_protocol"; "X-Forwarded-For";} real_ip_header $real_ip_header; Nginx при таком раскладе не ругается, но и не заменяет адрес ни на proxy_protocol_add, ни на X-Forwarded-For.Может кто-нибудь уже с таким сталкивался? Был бы очень благодарен. nginx version: nginx/1.9.4built by gcc 4.9.2 (Debian 4.9.2-10)built with OpenSSL 1.0.1k 8 Jan 2015TLS SNI support enabledconfigure arguments: --with-ld-opt=-Wl,-rpath,/usr/local/lib --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-stream_ssl_module --with-http_realip_module --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_spdy_module --with-threads --with-http_geoip_module --with-ipv6 --with-http_stub_status_module --add-module=/opt/ngx_devel_kit-0.2.19 --add-module=/opt/lua-nginx-module-0.9.17rc1___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: real_ip_header $variable

[Maxim Dounin]

Hello!

On Thu, Nov 12, 2015 at 05:08:38PM +0300, Den Bozhok wrote:

[...]

>должно хватать. но проблема еще в том, что перед elb балансировщиком
>может быть qrator или его аналог, соответственно нам нужно достать
>информацию об адресе клиента уже основываясь не исходящий ip адрес
>запроса,
> 
>а на заголовок X-Forwarded-For.

[...]

>real_ip_header $real_ip_header;
> 
>Nginx при таком раскладе не ругается, но и не заменяет адрес ни на
>proxy_protocol_add, ни на X-Forwarded-For.

Директива real_ip_header переменных не понимает, и в результате у 
вас nginx пытается получить адрес из заголовка c именем 
"$real_ip_header".

>Может кто-нибудь уже с таким сталкивался? Был бы очень благодарен.

FAIK, ELB умеет передавать адрес не только через PROXY protocol, 
но и через X-Forwarded-For.  Унифицируйте механизм получения 
адреса клиента - и будет вам счастье.

-- 
Maxim Dounin
http://nginx.org/

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: real_ip_header $variable

[Den Bozhok]

Благодарю за ответ! FAIK, ELB умеет передавать адрес не только через PROXY protocol, но и через X-Forwarded-For. Унифицируйте механизм получения адреса клиента - и будет вам счастье. Да, согласен, это при условии если протокол общения - http.В нашем случае http нам не подходит ибо ELB поддерживает максимум один SSL сертификат на порту. Поэтому трансляция идет в режиме TCP + proxy_protocol, что бы и с SSL проблем не было и http2 нормально работал + real ip были действительно real. 12.11.2015, 17:35, "Maxim Dounin" :Hello!On Thu, Nov 12, 2015 at 05:08:38PM +0300, Den Bozhok wrote:[...]должно хватать. но проблема еще в том, что перед elb балансировщикомможет быть qrator или его аналог, соответственно нам нужно достатьинформацию об адресе клиента уже основываясь не исходящий ip адресзапроса,а на заголовок X-Forwarded-For.[...]real_ip_header $real_ip_header;Nginx при таком раскладе не ругается, но и не заменяет адрес ни наproxy_protocol_add, ни на X-Forwarded-For.Директива real_ip_header переменных не понимает, и в результате у вас nginx пытается получить адрес из заголовка c именем "$real_ip_header".Может кто-нибудь уже с таким сталкивался? Был бы очень благодарен.FAIK, ELB умеет передавать адрес не только через PROXY protocol, но и через X-Forwarded-For.  Унифицируйте механизм получения адреса клиента - и будет вам счастье.-- Maxim Douninhttp://nginx.org/___nginx-ru mailing listnginx-ru@nginx.orghttp://mailman.nginx.org/mailman/listinfo/nginx-ru___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Работа с кастомными дублирующимися HTTP-заголовками запроса

[Александр Попков]

 Здравствуйте!

Как ни странно не смог нагуглить ничего по этому вопросу.

Есть клиент, который шлет в HTTP-запросе кастомный заголовок, иногда 
дублирующийся.

Например

X-Custom-Header: value1
X-Custom-Header: value2

Нам в конфиге nginx нужно получить значение этого заголовка, для чего мы 
используем переменную $http_x_custom_header.
В случае дублирования заголовков в эту переменную попадает только первое 
значение.
Конкретно в примере выше - переменная $http_x_custom_header будет равна 
"value1".

Не нашли никаких настроек этого поведения.
Есть ли штатные способы получить на уровне конфига nginx второе (на самом деле 
последнее) значение?

Если это важно:
 - версия nginx 1.8.0
 - значение последнего заголовка с таким названием нужно дальше использовать в 
таком блоке:
    map $is_case_success $fixed_custom_header {
    0 "";
    1 $http_x_custom_header; # хотим тут "value2" а не "value1"
    }

Заранее большое спасибо за помощь!

-- 
С Уважением, Александр.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru