Nginx Forum - Nginx Mailing List - Russian

400 Bad Request в Mercurial

kasak — Mon, 20 May 2013 00:31:10 -0400

Имеется репозиторий на меркуриале, работает через Apache на внутреннем сервере, nginx стоит на шлюзе и проксирует запросы на внутренний сервер. С определённого момента стало невозможным через nginx сделать pull, хотя clone работает. При попытке сделать pull получаем 400:bad request.

В error.log ничего, вот конфиг:

server {
listen 80;
server_name hg.somesite.ru;
large_client_header_buffers 4 128k;
location / {
proxy_pass http://al-dabaran;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Proxy-host $proxy_host;
client_max_body_size 400m;
client_body_buffer_size 128k;
proxy_buffering off;
proxy_connect_timeout 3600;
proxy_send_timeout 3600;
proxy_read_timeout 3600;
proxy_buffer_size 8k;
proxy_buffers 8 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}

}

Если пытаться сделать pull не через nginx а напрямую всё работает. Пробовал так же прокинуть порт на шлюзе, тоже работает. Не работает только через nginx. nginx версии 1.2.8 родной из openbsd.
Может есть хотя бы какой-нибудь способ протрассировать почему не пашет?
Все эти опции в конфиге я уже добавлял по факту того что без них перестало работать, и с ними тоже не работает. Первое что увидел в гугле - large_client_header_buffers, менял в разных вариациях - ничего не помогло. Вот и понеслось..
Заранее спасибо за ответы

Re: [SPAM]Как отдавать для deny IP; вместо 403 - 503?

kav — Sun, 19 May 2013 03:38:01 -0400

On 17.05.2013, at 20:10, Vladislav Prodan wrote:

>
> Сабж.
>
> Список IP глобальный, определен выше секций server.
как временная мера - список и пр части конфига можно заинклудить в любом месте

>
> Поэтому такая схема не помогает:
>
> error_page 403 = @403;
>
> location @403 {
> keepalive_timeout 0;
> return 503;
> }
>
> --
> Vladislav V. Prodan
> System & Network Administrator
> http://support.od.ua
> +380 67 4584408, +380 99 4060508
> VVP88-RIPE
>
> _______________________________________________
> 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

Уведомление модуля о том, что сессия завершилась

megalodon — Sat, 18 May 2013 05:17:00 -0400

Всем доброго дня.

Пишу модуль под nginx.

Управление передается модулю, когда прилетает request и наступает соответсвующая фаза обработки. Но, что если запрос не прилетел, а сессия закрылась по тайм-ауту со стороны nginx либо от клиента явно прилетел FIN или RST? Как при наступлении такого события можно передать упраление в модуль?

Заранее спасибо.

Как отдавать для deny IP; вместо 403 - 503?

Vladislav Prodan — Fri, 17 May 2013 12:12:01 -0400

Сабж.

Список IP глобальный, определен выше секций server.

Поэтому такая схема не помогает:

error_page 403 = @403;

location @403 {
keepalive_timeout 0;
return 503;
}

--
Vladislav V. Prodan
System & Network Administrator
http://support.od.ua
+380 67 4584408, +380 99 4060508
VVP88-RIPE

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

Re: Amazon ELB = Nginx ?

Andrei Belov — Fri, 17 May 2013 06:52:01 -0400

On May 17, 2013, at 14:35 , ast wrote:

> Всем привет. Из чистого любопытства:)
>
> http://www.e-xecutive.ru/startup/story/1823978/
>
> Есть такое интервью. В нем есть вот эта фраза:
>
> "На третье направление сейчас делаем основную ставку ― это коммерческий
> продукт на базе Nginx, над которым мы два года работаем. Фактически это тот
> же Nginx с открытым кодом плюс компоненты с закрытым кодом. Продукт уже
> доступен в облаке Amazon"
>
> Была не очень подтвержденная инфа, что амазоновский ELB использует
> модифицированный Nginx. Насколько я понимаю, то теперь это подтверждается
> точно?

Нет, ELB тут ни при чём.

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

Amazon ELB = Nginx ?

ast — Fri, 17 May 2013 06:35:03 -0400

Всем привет. Из чистого любопытства:)

http://www.e-xecutive.ru/startup/story/1823978/

Есть такое интервью. В нем есть вот эта фраза:

"На третье направление сейчас делаем основную ставку ― это коммерческий продукт на базе Nginx, над которым мы два года работаем. Фактически это тот же Nginx с открытым кодом плюс компоненты с закрытым кодом. Продукт уже доступен в облаке Amazon"

Была не очень подтвержденная инфа, что амазоновский ELB использует модифицированный Nginx. Насколько я понимаю, то теперь это подтверждается точно?

Re: proxy pass через переменную не работает

Vadim Lazovskiy — Fri, 17 May 2013 01:46:02 -0400

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

Задайте http://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver в
конфиге.

2013/5/17 bespechnost

> Пробую так:
> location /omlet_api/ {
> proxy_pass http://$arg_server/;
> proxy_set_header Host $arg_server;
> break;
> }
>
> В логах:
> ==> localhost.error_log <==
> 2013/05/17 08:48:59 [error] 16907#0: *1 no resolver defined to resolve
> ya.ru, client: 127.0.0.1, server: localhost, request: "GET
> /omlet_api/genres/?server=ya.ru HTTP/1.1", host: "localhost"
>
> Если заменить $arg_server на имя сервера, то все работает.
>
> Версия NGINX - 1.2.6-r1
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,239286,239286#msg-239286
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

--
Best Regards,
Vadim Lazovskiy
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

proxy_pass через переменную не работает

bespechnost — Fri, 17 May 2013 00:55:28 -0400

Пробую так:
location /omlet_api/ {
proxy_pass http://$arg_server/;
proxy_set_header Host $arg_server;
break;
}

В логах:
==> localhost.error_log <==
2013/05/17 08:48:59 [error] 16907#0: *1 no resolver defined to resolve ya.ru, client: 127.0.0.1, server: localhost, request: "GET /omlet_api/genres/?server=ya.ru HTTP/1.1", host: "localhost"

Если заменить $arg_server на имя сервера, то все работает.

Версия NGINX - 1.2.6-r1

Re: nginx location single php file

Andrey Kopeyko — Thu, 16 May 2013 13:16:06 -0400

16.05.2013 16:22, skeletor пишет:
> Спасибо всем за помощь.
> Проблема была на поверхности, а именно - не слушался порт 9000.

Вы какую-то пургу несёте - если бы дело было именно в этом, вы бы
получали "502". Вы же получали "401", а это значит что Максим прав - ваш
запрос обрабатывался в каком-то другом локейшене. Включите уж debug log
да и посмотрите.

То, что у вас всё теперь заработало - говорит не о том, что вы
разобрались и искоренили проблему, а, скорее, о случайности - какое-то
другое ваше изменение, в той части конфига что вы не показали, привело к
тому что обработка запроса стала попадать в этот локейшн.

Следующее ваше изменение конфига - запросто может развалить всё вновь,
готовьтесь.

--
Best regards,
Andrey Kopeyko

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

Re: location и proxy pass

Maxim Dounin — Thu, 16 May 2013 09:12:02 -0400

Hello!

On Thu, May 16, 2013 at 07:12:57AM -0400, AMax wrote:

> Есть такой server:
>
> server {
> listen 80;
> server_name example.com www.example.com;
>
> access_log /var/log/nginx/example.com/access.log main;
> error_log /var/log/nginx/example.com/error.log;
> include /etc/nginx/cloudflare_params;
>
> location /w/images/ {
> root /var/www/data/example.com;
> # log only hotlinking
> if ($http_referer ~* "^http://(www\.)?example\.com/.*$" ) {
> access_log off;
> }
> }
>
> location /w/skins/ {
> root /var/www/data/example.com;
> access_log off;
> }
>
> location ~ ^/w/extensions/.*?\.(sql|php)$ { return 403; }
>
> # location ^~ /w/load.php {
> # proxy_pass http://127.0.0.1:81/;
> # include /etc/nginx/proxy_params;
> # access_log off;
> # }
>
> location / {
> proxy_pass http://127.0.0.1:81/;
> include /etc/nginx/proxy_params;
> }
> }
>
> Если раскомментировать location ^~ /w/load.php, он перестает работать,
> точнее возвращает некорректный ответ от сервера, хотя, вроде бы, должен
> обрабатываться тем же backend с теми же параметрами, только не писать в
> журнал.

Поскольку используется proxy_pass с URI - указанный URI заменяет
совпавшую с location'ом часть URI запроса. Для location / -
замена "/" на "/" ни на что не влияет, а вот для location
/w/load.php - замена "/w/load.php" на "/" логично приводит к тому,
что оно перестаёт работать.

Проще всего убрать "/" в конце proxy_pass:

location = /w/load.php {
proxy_pass http://127.0.0.1:81;
...
}

Подробнее см. http://nginx.org/r/proxy_pass/ru.

--
Maxim Dounin
http://nginx.org/en/donation.html

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

Re: nginx location single php file

skeletor — Thu, 16 May 2013 08:22:58 -0400

Спасибо всем за помощь.
Проблема была на поверхности, а именно - не слушался порт 9000. То есть банально php-fpm не работал. Вот, правильный (работает и тот, но этот точнее будет; как видно отличие только в = и ~)

location = /rpc.php {
auth_basic off;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param DOCUMENT_ROOT /www;
fastcgi_param SCRIPT_FILENAME /www$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED /www$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param GATEWAY_INTERFACE "CGI/1.1";
fastcgi_param SERVER_NAME $server_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param REMOTE_USER $remote_user;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param GEOIP_COUNTRY_CODE $geoip_city_country_code;
fastcgi_param GEOIP_COUNTRY_NAME $geoip_city_country_name;
fastcgi_param GEOIP_REGION $geoip_region;
fastcgi_param GEOIP_CITY $geoip_city;
}

Re: nginx location single php file

skeletor — Thu, 16 May 2013 07:45:36 -0400

Проверяю curl'ом.
Для теста поместил в файл rpc.php текст .

Re: nginx location single php file

Dmitry Ivanov — Thu, 16 May 2013 07:14:02 -0400

Здравствуйте, skeletor.

Вы писали 16 мая 2013 г., 13:35:10:

> Всем привет.
> Нужно отключить basic авторизацию для запроса
> http://domain.com/rpc.php?jkfgsdkfg. Для всего сайта включена basic
> авторизация. Создаю новый location :

Наверняка подсасывается чот-то, не лежащее в /rpc.php (картинки, css
etc)

Посмотрите тем же Хромом (Инструменты разработчка - Network), что на
самом деле запрашивается.

Сам вчера наступил на такое.
--
С уважением,
Dmitry mailto:nginx-ru@sadok.spb.ru

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

location и proxy_pass

AMax — Thu, 16 May 2013 07:12:57 -0400

Есть такой server:

server {
listen 80;
server_name example.com www.example.com;

access_log /var/log/nginx/example.com/access.log main;
error_log /var/log/nginx/example.com/error.log;
include /etc/nginx/cloudflare_params;

location /w/images/ {
root /var/www/data/example.com;
# log only hotlinking
if ($http_referer ~* "^http://(www\.)?example\.com/.*$" ) {
access_log off;
}
}

location /w/skins/ {
root /var/www/data/example.com;
access_log off;
}

location ~ ^/w/extensions/.*?\.(sql|php)$ { return 403; }

# location ^~ /w/load.php {
# proxy_pass http://127.0.0.1:81/;
# include /etc/nginx/proxy_params;
# access_log off;
# }

location / {
proxy_pass http://127.0.0.1:81/;
include /etc/nginx/proxy_params;
}
}

Если раскомментировать location ^~ /w/load.php, он перестает работать, точнее возвращает некорректный ответ от сервера, хотя, вроде бы, должен обрабатываться тем же backend с теми же параметрами, только не писать в журнал.

Re: nginx location single php file

Maxim Dounin — Thu, 16 May 2013 07:12:01 -0400

Hello!

On Thu, May 16, 2013 at 06:19:33AM -0400, skeletor wrote:

> Спасибо за наводку, но вижу только обработку server_name (там у меня
> regexp).

Видимо, nginx собран без debug'а. Подробнее тут:

http://nginx.org/ru/docs/debugging_log.html

> Nginx собран без модуля echo, а без него протестировать location'ы
> невозможно.

Способов масса, начиная от "return 418;" (или более гуманного
return 200 OK;") в проверяемом месте. Хотя проще всего - с debug
log'ом, как Андрей уже порекомендовал.

Впрочем, заявленное "не работает location = /rpc.php" говорит о
том, что выбор location'а - не при чём, и проблема в чём-то
другом. E.g., если вы тестируете браузером, - авторизация может
запрышиваться не для самой страницы, а для дополнительных ресурсов -
картинок и т.п. - которые грузятся с других адресов.

--
Maxim Dounin
http://nginx.org/en/donation.html

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

Re: nginx location single php file

skeletor — Thu, 16 May 2013 06:19:33 -0400

Спасибо за наводку, но вижу только обработку server_name (там у меня regexp). Nginx собран без модуля echo, а без него протестировать location'ы невозможно.

Re: nginx location single php file

Andrey Kopeyko — Thu, 16 May 2013 05:54:01 -0400

16.05.2013 13:35, skeletor пишет:
> Всем привет.

Добрый день!

> Нужно отключить basic авторизацию для запроса
...
> Не могу понять, почему запрашивается basic авторизация при запросе
> http://domain.com/rpc.php и как её отключить.

А вы включите debug log и почитайте как же на самом деле ваш запрос
обрабатывается.

--
Best regards,
Andrey Kopeyko

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

nginx location single php file

skeletor — Thu, 16 May 2013 05:35:10 -0400

Всем привет.
Нужно отключить basic авторизацию для запроса http://domain.com/rpc.php?jkfgsdkfg. Для всего сайта включена basic авторизация. Создаю новый location :

location ~ /rpc.php {
auth_basic off;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param DOCUMENT_ROOT /www;
fastcgi_param SCRIPT_FILENAME /www$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED /www$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param GATEWAY_INTERFACE "CGI/1.1";
fastcgi_param SERVER_NAME $server_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param REMOTE_USER $remote_user;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param GEOIP_COUNTRY_CODE $geoip_city_country_code;
fastcgi_param GEOIP_COUNTRY_NAME $geoip_city_country_name;
fastcgi_param GEOIP_REGION $geoip_region;
fastcgi_param GEOIP_CITY $geoip_city;
}

Но не работает (то есть, всё равно требуется авторизация). Хотя вот такие location'ы вполне работают (то есть, при запросе http://domain.com/ajax/jfsgf.php?fhfsl - basic авторизация не запрашивается):

location /ajax {
auth_basic off;
alias /www/ajax;
}
location ~ /ajax/(.*\.php)$ {
auth_basic off;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param DOCUMENT_ROOT /www;
fastcgi_param SCRIPT_FILENAME /www$fastcgi_script_name;
fastcgi_param PATH_TRANSLATED /www$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param GATEWAY_INTERFACE "CGI/1.1";
fastcgi_param SERVER_NAME $server_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param REMOTE_USER $remote_user;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param GEOIP_COUNTRY_CODE $geoip_city_country_code;
fastcgi_param GEOIP_COUNTRY_NAME $geoip_city_country_name;
fastcgi_param GEOIP_REGION $geoip_region;
fastcgi_param GEOIP_CITY $geoip_city;
}

Не могу понять, почему запрашивается basic авторизация при запросе http://domain.com/rpc.php и как её отключить.
Уже по разному пробовал location менять:

location = /rpc.php
location /rpc.php

не работает.

Re: Доступ по ip ИЛИ через клиентский сертификат - возможно ли?

Илья Шипицин — Wed, 15 May 2013 08:54:03 -0400

если требовать сертификат, то в случае, если сертификат не предъявлен,
nginx генерирует внутреннюю ошибку 495.

делаете "error_page 495 = @fallback;", все, кто пришел без
сертификата, отправляются в @fallback, там пробиваете по IP.

как-то так.

15 мая 2013 г., 15:46 пользователь itonohito написал:
> Добрый день!
>
> Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к
> сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip?
> Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с
> любого ip, а кроме того - с некоторых ip доступ был для всех и без
> сертификата тоже.
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?21,239218,239218#msg-239218
>
> _______________________________________________
> 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

Re: Доступ по ip ИЛИ через клиентский сертификат - возможно ли?

Pavel V. — Wed, 15 May 2013 07:00:01 -0400

Здравствуйте, itonohito.

Вы писали 15 мая 2013 г., 16:46:22:

> Добрый день!

> Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к
> сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip?
> Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с
> любого ip, а кроме того - с некоторых ip доступ был для всех и без
> сертификата тоже.

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

Вы можете сконфигурировать отдельный server {} на отдельном порту, разрешающий доступ по IP без
требования сертификата, и завернуть трафик с "некоторых IP" на этот порт, например через
iptables -t nat -I PREROUTING -s 1.2.3.4/25 -d 8.8.7.7 -p tcp --dport 443 -j DNAT --to-destination=8.8.7.7:444

--
С уважением,
Pavel mailto:pavel2000@ngs.ru

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

Доступ по ip ИЛИ через клиентский сертификат - возможно ли?

itonohito — Wed, 15 May 2013 05:46:22 -0400

Добрый день!

Уважаемые гуру, подскажите, возможно ли средствами nginx сделать доступ к сайту с определенных ip ИЛИ через клиентские сертификаты с любого ip?
Т.е. чтобы клиент с установленным клиентским сертификатом получал доступ с любого ip, а кроме того - с некоторых ip доступ был для всех и без сертификата тоже.

Re: Крякозябы в кешированных файлах proxy store

r3l0c — Wed, 15 May 2013 01:55:26 -0400

Решил проблему, был включен gzip, но хз почему такой косяк был

Re: Re[2]: патч для Connection: Keep-Alive

Blangel — Tue, 14 May 2013 12:44:18 -0400

Михаил Монашёв Wrote:
-------------------------------------------------------
> Здравствуйте, Илья.
>
> > у нас 50 миллионов запросов в день. это в районе 1 гигабайта на
> > хедерах "Connection:". нам эта цифра интересна.
> > мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту.
>
> Это не нужная экономия. Актуально может было бы ещё тем, кто браузером
> ходит через узкий канал, но уж точно не тем, кто раздаёт контент.

Узкий канал => Transfer-Encoding: chunked => отсутствует Content-Length =>
=> Какая разница, есть заголовок Connection или нет?
Клиент все равно не знает,
когда закончится ответ сервера, пока сервер не закончит.

В случае с Keep-Alive это не сломается, потому что Google не отдает Keep-Alive,
и вроде бы забаненных в Гугле мы не наблюдаем....

В случае с Close тоже не сломается, потому что клиент все равно
не знает, когда закрыть соединение - т.е. решает сервер.

Re: патч для Connection: Keep-Alive

Maxim Dounin — Tue, 14 May 2013 12:40:01 -0400

Hello!

On Tue, May 14, 2013 at 10:24:31PM +0600, Илья Шипицин wrote:

> не слать "Connection: Keep-Alive" для HTTP/1.1 - статистически то же
> самое, что я предлагал (ввиду малораспространенности
> не-кипэлайв-соединений)
>
> давайте так и сделаем ?

Я очень не хочу это трогать, по крайней мере - без тщательного
тестирования.

> вариант "не слать Connection никогда" мы на кошках проверим, потом расскажу.

В рассылках периодически жалуются даже на те очень нечастые
ситуцаии, когда nginx так всё-таки делает (e.g., при
переконфигурации).

>
> 14 мая 2013 г., 22:17 пользователь Maxim Dounin написал:
> > Hello!
> >
> > On Tue, May 14, 2013 at 09:39:42PM +0600, Илья Шипицин wrote:
> >
> >> 14 мая 2013 г., 21:16 пользователь Maxim Dounin написал:
> >> > Hello!
> >> >
> >> > On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote:
> >> >
> >> > [...]
> >> >
> >> >> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся
> >> >> также и Connection. не вижу ничего некорректного. можете уточнить ?
> >> >>
> >> >> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там,
> >> >> где предполагалось. да, признаю ошибку. вложил новый патч.
> >> >
> >> > Это я не досмотрел патч, и предположил не ту ошибку из двух
> >> > возможных.
> >> >
> >> > [...]
> >> >
> >> >> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013
> >> >> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013
> >> >> @@ -382,7 +382,7 @@
> >> >> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) {
> >> >> len += sizeof("Connection: upgrade" CRLF) - 1;
> >> >>
> >> >> - } else if (r->keepalive) {
> >> >> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) {
> >> >> len += sizeof("Connection: keep-alive" CRLF) - 1;
> >> >>
> >> >> /*
> >> >> @@ -397,9 +397,7 @@
> >> >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2;
> >> >> }
> >> >>
> >> >> - } else {
> >> >> - len += sizeof("Connection: close" CRLF) - 1;
> >> >> - }
> >> >> + }
> >> >
> >> > "Connection: close" при выключенном keepalive'е нужно указывать,
> >> > не возвращать соответствующий заголовок - чревато ненужными
> >> > проблемами и безуспешными попытками клиентов послать в то же
> >> > соединение следующий запрос.
> >> >
> >>
> >> я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616
> >>
> >> 8.1.4 Practical Considerations
> >>
> >>
> >> ........
> >>
> >> A client, server, or proxy MAY close the transport connection at any
> >> time.
> >> .........
> >>
> >>
> >>
> >
> > Это _можно_ делать, но на практике - это приводит к сильно
> > неоптимальному поведению клиентов. Поэтому убирать "Connection:
> > close" из ответов, keepalive в которых не предполагается - это
> > плохая идея.
> >
> > С учётом того, что keepalive в нормальных условиях влючён чуть
> > более, чем всегда - убирать "Connection: close" не представляется
> > разумным ни с какой точки зрения.
> >
> >> с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16%
> >> сайтов), как-то же это работает ...
> >
> > Специально сходил проверил на первый попавшийся сайт с IIS'ом -
> > _так_ IIS, насколько я вижу, не поступает:
> >
> > $ telnet W3schools.com 80
> > Trying 66.29.212.73...
> > Connected to W3schools.com.
> > Escape character is '^]'.
> > HEAD / HTTP/1.1
> > Host: w3scools.com
> >
> > HTTP/1.1 200 OK
> > Cache-Control: private
> > Content-Length: 29839
> > Content-Type: text/html
> > Server: Microsoft-IIS/7.5
> > Set-Cookie: ASPSESSIONIDCABDDTCD=OMAGHFBBMDCIEKCKOIEGKPAO; path=/
> > X-Powered-By: ASP.NET
> > Date: Tue, 14 May 2013 16:10:08 GMT
> >
> > HEAD / HTTP/1.1
> > Host: w3scools.com
> > Connection: close
> >
> > HTTP/1.1 200 OK
> > Cache-Control: private
> > Content-Length: 29839
> > Content-Type: text/html
> > Server: Microsoft-IIS/7.5
> > Set-Cookie: ASPSESSIONIDCABDDTCD=MICGHFBBKNHMJHAFKDAJJOJD; path=/
> > X-Powered-By: ASP.NET
> > Date: Tue, 14 May 2013 16:10:28 GMT
> > Connection: close
> >
> > Connection closed by foreign host.
> >
> > Т.е. если соединение закрывается - то "Connection: close" в ответе
> > присутствует.
> >
> >> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на
> >> хедерах "Connection:". нам эта цифра интересна.
> >> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту.
> >>
> >>
> >> > Вообще я бы, честно говоря, не трогал это место.
> >>
> >> это абстрактные опасения или вы знаете сценарии, при которых это
> >> приведет к проблемам ?
> >
> > При правильной реализации - т.е. не слать "Connection: keep-alive"
> > для соединений по HTTP/1.1, если заголовок Keep-Alive не отдаётся -
> > только абстрактные. Все изложенные выше замечания - вполне
> > конкретные.
> >
> > Just in case, правильный патч какой-то такой:
> >
> > --- a/src/http/ngx_http_header_filter_module.c
> > +++ b/src/http/ngx_http_header_filter_module.c
> > @@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_
> > len += sizeof("Connection: upgrade" CRLF) - 1;
> >
> > } else if (r->keepalive) {
> > - len += sizeof("Connection: keep-alive" CRLF) - 1;
> > +
> > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) {
> > + len += sizeof("Connection: keep-alive" CRLF) - 1;
> > + }
> >
> > /*
> > * MSIE and Opera ignore the "Keep-Alive: timeout=" header.
> > @@ -556,8 +559,11 @@ ngx_http_header_filter(ngx_http_request_
> > sizeof("Connection: upgrade" CRLF) - 1);
> >
> > } else if (r->keepalive) {
> > - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
> > - sizeof("Connection: keep-alive" CRLF) - 1);
> > +
> > + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) {
> > + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
> > + sizeof("Connection: keep-alive" CRLF) - 1);
> > + }
> >
> > if (clcf->keepalive_header) {
> > b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF,
> >
> >
> > --
> > Maxim Dounin
> > http://nginx.org/en/donation.html
> >
> > _______________________________________________
> > 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

--
Maxim Dounin
http://nginx.org/en/donation.html

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

Re: патч для Connection: Keep-Alive

Илья Шипицин — Tue, 14 May 2013 12:26:01 -0400

не слать "Connection: Keep-Alive" для HTTP/1.1 - статистически то же
самое, что я предлагал (ввиду малораспространенности
не-кипэлайв-соединений)

давайте так и сделаем ?

вариант "не слать Connection никогда" мы на кошках проверим, потом расскажу.

14 мая 2013 г., 22:17 пользователь Maxim Dounin написал:
> Hello!
>
> On Tue, May 14, 2013 at 09:39:42PM +0600, Илья Шипицин wrote:
>
>> 14 мая 2013 г., 21:16 пользователь Maxim Dounin написал:
>> > Hello!
>> >
>> > On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote:
>> >
>> > [...]
>> >
>> >> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся
>> >> также и Connection. не вижу ничего некорректного. можете уточнить ?
>> >>
>> >> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там,
>> >> где предполагалось. да, признаю ошибку. вложил новый патч.
>> >
>> > Это я не досмотрел патч, и предположил не ту ошибку из двух
>> > возможных.
>> >
>> > [...]
>> >
>> >> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013
>> >> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013
>> >> @@ -382,7 +382,7 @@
>> >> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) {
>> >> len += sizeof("Connection: upgrade" CRLF) - 1;
>> >>
>> >> - } else if (r->keepalive) {
>> >> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) {
>> >> len += sizeof("Connection: keep-alive" CRLF) - 1;
>> >>
>> >> /*
>> >> @@ -397,9 +397,7 @@
>> >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2;
>> >> }
>> >>
>> >> - } else {
>> >> - len += sizeof("Connection: close" CRLF) - 1;
>> >> - }
>> >> + }
>> >
>> > "Connection: close" при выключенном keepalive'е нужно указывать,
>> > не возвращать соответствующий заголовок - чревато ненужными
>> > проблемами и безуспешными попытками клиентов послать в то же
>> > соединение следующий запрос.
>> >
>>
>> я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616
>>
>> 8.1.4 Practical Considerations
>>
>>
>> ........
>>
>> A client, server, or proxy MAY close the transport connection at any
>> time.
>> .........
>>
>>
>>
>
> Это _можно_ делать, но на практике - это приводит к сильно
> неоптимальному поведению клиентов. Поэтому убирать "Connection:
> close" из ответов, keepalive в которых не предполагается - это
> плохая идея.
>
> С учётом того, что keepalive в нормальных условиях влючён чуть
> более, чем всегда - убирать "Connection: close" не представляется
> разумным ни с какой точки зрения.
>
>> с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16%
>> сайтов), как-то же это работает ...
>
> Специально сходил проверил на первый попавшийся сайт с IIS'ом -
> _так_ IIS, насколько я вижу, не поступает:
>
> $ telnet W3schools.com 80
> Trying 66.29.212.73...
> Connected to W3schools.com.
> Escape character is '^]'.
> HEAD / HTTP/1.1
> Host: w3scools.com
>
> HTTP/1.1 200 OK
> Cache-Control: private
> Content-Length: 29839
> Content-Type: text/html
> Server: Microsoft-IIS/7.5
> Set-Cookie: ASPSESSIONIDCABDDTCD=OMAGHFBBMDCIEKCKOIEGKPAO; path=/
> X-Powered-By: ASP.NET
> Date: Tue, 14 May 2013 16:10:08 GMT
>
> HEAD / HTTP/1.1
> Host: w3scools.com
> Connection: close
>
> HTTP/1.1 200 OK
> Cache-Control: private
> Content-Length: 29839
> Content-Type: text/html
> Server: Microsoft-IIS/7.5
> Set-Cookie: ASPSESSIONIDCABDDTCD=MICGHFBBKNHMJHAFKDAJJOJD; path=/
> X-Powered-By: ASP.NET
> Date: Tue, 14 May 2013 16:10:28 GMT
> Connection: close
>
> Connection closed by foreign host.
>
> Т.е. если соединение закрывается - то "Connection: close" в ответе
> присутствует.
>
>> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на
>> хедерах "Connection:". нам эта цифра интересна.
>> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту.
>>
>>
>> > Вообще я бы, честно говоря, не трогал это место.
>>
>> это абстрактные опасения или вы знаете сценарии, при которых это
>> приведет к проблемам ?
>
> При правильной реализации - т.е. не слать "Connection: keep-alive"
> для соединений по HTTP/1.1, если заголовок Keep-Alive не отдаётся -
> только абстрактные. Все изложенные выше замечания - вполне
> конкретные.
>
> Just in case, правильный патч какой-то такой:
>
> --- a/src/http/ngx_http_header_filter_module.c
> +++ b/src/http/ngx_http_header_filter_module.c
> @@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_
> len += sizeof("Connection: upgrade" CRLF) - 1;
>
> } else if (r->keepalive) {
> - len += sizeof("Connection: keep-alive" CRLF) - 1;
> +
> + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) {
> + len += sizeof("Connection: keep-alive" CRLF) - 1;
> + }
>
> /*
> * MSIE and Opera ignore the "Keep-Alive: timeout=" header.
> @@ -556,8 +559,11 @@ ngx_http_header_filter(ngx_http_request_
> sizeof("Connection: upgrade" CRLF) - 1);
>
> } else if (r->keepalive) {
> - b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
> - sizeof("Connection: keep-alive" CRLF) - 1);
> +
> + if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) {
> + b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
> + sizeof("Connection: keep-alive" CRLF) - 1);
> + }
>
> if (clcf->keepalive_header) {
> b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF,
>
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> 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

Re: патч для Connection: Keep-Alive

Maxim Dounin — Tue, 14 May 2013 12:18:01 -0400

Hello!

On Tue, May 14, 2013 at 09:39:42PM +0600, Илья Шипицин wrote:

> 14 мая 2013 г., 21:16 пользователь Maxim Dounin написал:
> > Hello!
> >
> > On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote:
> >
> > [...]
> >
> >> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся
> >> также и Connection. не вижу ничего некорректного. можете уточнить ?
> >>
> >> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там,
> >> где предполагалось. да, признаю ошибку. вложил новый патч.
> >
> > Это я не досмотрел патч, и предположил не ту ошибку из двух
> > возможных.
> >
> > [...]
> >
> >> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013
> >> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013
> >> @@ -382,7 +382,7 @@
> >> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) {
> >> len += sizeof("Connection: upgrade" CRLF) - 1;
> >>
> >> - } else if (r->keepalive) {
> >> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) {
> >> len += sizeof("Connection: keep-alive" CRLF) - 1;
> >>
> >> /*
> >> @@ -397,9 +397,7 @@
> >> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2;
> >> }
> >>
> >> - } else {
> >> - len += sizeof("Connection: close" CRLF) - 1;
> >> - }
> >> + }
> >
> > "Connection: close" при выключенном keepalive'е нужно указывать,
> > не возвращать соответствующий заголовок - чревато ненужными
> > проблемами и безуспешными попытками клиентов послать в то же
> > соединение следующий запрос.
> >
>
> я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616
>
> 8.1.4 Practical Considerations
>
>
> ........
>
> A client, server, or proxy MAY close the transport connection at any
> time.
> .........
>
>
>

Это _можно_ делать, но на практике - это приводит к сильно
неоптимальному поведению клиентов. Поэтому убирать "Connection:
close" из ответов, keepalive в которых не предполагается - это
плохая идея.

С учётом того, что keepalive в нормальных условиях влючён чуть
более, чем всегда - убирать "Connection: close" не представляется
разумным ни с какой точки зрения.

> с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16%
> сайтов), как-то же это работает ...

Специально сходил проверил на первый попавшийся сайт с IIS'ом -
_так_ IIS, насколько я вижу, не поступает:

$ telnet W3schools.com 80
Trying 66.29.212.73...
Connected to W3schools.com.
Escape character is '^]'.
HEAD / HTTP/1.1
Host: w3scools.com

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 29839
Content-Type: text/html
Server: Microsoft-IIS/7.5
Set-Cookie: ASPSESSIONIDCABDDTCD=OMAGHFBBMDCIEKCKOIEGKPAO; path=/
X-Powered-By: ASP.NET
Date: Tue, 14 May 2013 16:10:08 GMT

HEAD / HTTP/1.1
Host: w3scools.com
Connection: close

HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 29839
Content-Type: text/html
Server: Microsoft-IIS/7.5
Set-Cookie: ASPSESSIONIDCABDDTCD=MICGHFBBKNHMJHAFKDAJJOJD; path=/
X-Powered-By: ASP.NET
Date: Tue, 14 May 2013 16:10:28 GMT
Connection: close

Connection closed by foreign host.

Т.е. если соединение закрывается - то "Connection: close" в ответе
присутствует.

> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на
> хедерах "Connection:". нам эта цифра интересна.
> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту.
>
>
> > Вообще я бы, честно говоря, не трогал это место.
>
> это абстрактные опасения или вы знаете сценарии, при которых это
> приведет к проблемам ?

При правильной реализации - т.е. не слать "Connection: keep-alive"
для соединений по HTTP/1.1, если заголовок Keep-Alive не отдаётся -
только абстрактные. Все изложенные выше замечания - вполне
конкретные.

Just in case, правильный патч какой-то такой:

--- a/src/http/ngx_http_header_filter_module.c
+++ b/src/http/ngx_http_header_filter_module.c
@@ -383,7 +383,10 @@ ngx_http_header_filter(ngx_http_request_
len += sizeof("Connection: upgrade" CRLF) - 1;

} else if (r->keepalive) {
- len += sizeof("Connection: keep-alive" CRLF) - 1;
+
+ if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) {
+ len += sizeof("Connection: keep-alive" CRLF) - 1;
+ }

/*
* MSIE and Opera ignore the "Keep-Alive: timeout=" header.
@@ -556,8 +559,11 @@ ngx_http_header_filter(ngx_http_request_
sizeof("Connection: upgrade" CRLF) - 1);

} else if (r->keepalive) {
- b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
- sizeof("Connection: keep-alive" CRLF) - 1);
+
+ if (r->http_version < NGX_HTTP_VERSION_11 || clcf->keepalive_header) {
+ b->last = ngx_cpymem(b->last, "Connection: keep-alive" CRLF,
+ sizeof("Connection: keep-alive" CRLF) - 1);
+ }

if (clcf->keepalive_header) {
b->last = ngx_sprintf(b->last, "Keep-Alive: timeout=%T" CRLF,

--
Maxim Dounin
http://nginx.org/en/donation.html

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

Re: Re[2]: патч для Connection: Keep-Alive

Илья Шипицин — Tue, 14 May 2013 12:10:06 -0400

ну так, чтобы пользователю на узком канале прилетело меньше трафика,
надо меньше его отдать.

14 мая 2013 г., 22:05 пользователь Михаил Монашёв
написал:
> Здравствуйте, Илья.
>
>> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на
>> хедерах "Connection:". нам эта цифра интересна.
>> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту.
>
> Это не нужная экономия. Актуально может было бы ещё тем, кто браузером
> ходит через узкий канал, но уж точно не тем, кто раздаёт контент.
>
> --
> С уважением,
> Михаил mailto:postmaster@softsearch.ru
>
> _______________________________________________
> 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

Re[2]: патч для Connection: Keep-Alive

Михаил Монашёв — Tue, 14 May 2013 12:06:02 -0400

Здравствуйте, Илья.

> у нас 50 миллионов запросов в день. это в районе 1 гигабайта на
> хедерах "Connection:". нам эта цифра интересна.
> мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту.

Это не нужная экономия. Актуально может было бы ещё тем, кто браузером
ходит через узкий канал, но уж точно не тем, кто раздаёт контент.

--
С уважением,
Михаил mailto:postmaster@softsearch.ru

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

Re: патч для Connection: Keep-Alive

Илья Шипицин — Tue, 14 May 2013 11:40:01 -0400

14 мая 2013 г., 21:16 пользователь Maxim Dounin написал:
> Hello!
>
> On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote:
>
> [...]
>
>> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся
>> также и Connection. не вижу ничего некорректного. можете уточнить ?
>>
>> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там,
>> где предполагалось. да, признаю ошибку. вложил новый патч.
>
> Это я не досмотрел патч, и предположил не ту ошибку из двух
> возможных.
>
> [...]
>
>> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013
>> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013
>> @@ -382,7 +382,7 @@
>> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) {
>> len += sizeof("Connection: upgrade" CRLF) - 1;
>>
>> - } else if (r->keepalive) {
>> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) {
>> len += sizeof("Connection: keep-alive" CRLF) - 1;
>>
>> /*
>> @@ -397,9 +397,7 @@
>> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2;
>> }
>>
>> - } else {
>> - len += sizeof("Connection: close" CRLF) - 1;
>> - }
>> + }
>
> "Connection: close" при выключенном keepalive'е нужно указывать,
> не возвращать соответствующий заголовок - чревато ненужными
> проблемами и безуспешными попытками клиентов послать в то же
> соединение следующий запрос.
>

я понимаю ваши опасения, однако с точки зрения буквы закона, rfc 2616

8.1.4 Practical Considerations

........

A client, server, or proxy MAY close the transport connection at any
time.
.........

с точки зрения духа закона так поступает IIS (по данным Netcraft-а 16%
сайтов), как-то же это работает ...

у нас 50 миллионов запросов в день. это в районе 1 гигабайта на
хедерах "Connection:". нам эта цифра интересна.
мы, пожалуй, потестируем, всех желающих тоже приглашаю к тесту.

> Вообще я бы, честно говоря, не трогал это место.

это абстрактные опасения или вы знаете сценарии, при которых это
приведет к проблемам ?

>
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> 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

Re: патч для Connection: Keep-Alive

Maxim Dounin — Tue, 14 May 2013 11:18:01 -0400

Hello!

On Tue, May 14, 2013 at 06:15:05PM +0600, Илья Шипицин wrote:

[...]

> во всех случаях, когда добавлялся Keep-Alive: timeout, добавлялся
> также и Connection. не вижу ничего некорректного. можете уточнить ?
>
> другое дело, что я накосячил и не добавлял Keep-Alive: timeout там,
> где предполагалось. да, признаю ошибку. вложил новый патч.

Это я не досмотрел патч, и предположил не ту ошибку из двух
возможных.

[...]

> --- src/http/ngx_http_header_filter_module.c.orig Tue May 14 12:17:59 2013
> +++ src/http/ngx_http_header_filter_module.c Tue May 14 16:04:29 2013
> @@ -382,7 +382,7 @@
> if (r->headers_out.status == NGX_HTTP_SWITCHING_PROTOCOLS) {
> len += sizeof("Connection: upgrade" CRLF) - 1;
>
> - } else if (r->keepalive) {
> + } else if ((r->keepalive) && ((r->http_version == NGX_HTTP_VERSION_10) || (clcf->keepalive_header)) ) {
> len += sizeof("Connection: keep-alive" CRLF) - 1;
>
> /*
> @@ -397,9 +397,7 @@
> len += sizeof("Keep-Alive: timeout=") - 1 + NGX_TIME_T_LEN + 2;
> }
>
> - } else {
> - len += sizeof("Connection: close" CRLF) - 1;
> - }
> + }

"Connection: close" при выключенном keepalive'е нужно указывать,
не возвращать соответствующий заголовок - чревато ненужными
проблемами и безуспешными попытками клиентов послать в то же
соединение следующий запрос.

Вообще я бы, честно говоря, не трогал это место.

--
Maxim Dounin
http://nginx.org/en/donation.html

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