Re: патч для отключения заголовков "Connection: keep-alive" (еще раз)

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Dec 11, 2013 at 10:41:42PM +0600, Илья Шипицин wrote:

> 11 декабря 2013 г., 20:41 пользователь Maxim Dounin
> <mdounin@xxxxxxxxxx> написал:
> > Hello!
> >
> > On Wed, Dec 11, 2013 at 01:39:21AM +0600, Илья Шипицин wrote:
> >
> >> 11 декабря 2013 г., 0:43 пользователь Maxim Dounin <mdounin@xxxxxxxxxx> 
> >> написал:
> >> > Hello!
> >> >
> >> > On Tue, Dec 10, 2013 at 11:12:16PM +0600, Илья Шипицин wrote:
> >> >
> >> >> 10 декабря 2013 г., 22:37 пользователь Maxim Dounin
> >> >> <mdounin@xxxxxxxxxx> написал:
> >> >> > Hello!
> >> >> >
> >> >> > On Tue, Dec 10, 2013 at 09:22:02PM +0600, Илья Шипицин wrote:
> >> >> >
> >> >> >> 10 декабря 2013 г., 19:37 пользователь Maxim Dounin
> >> >> >> <mdounin@xxxxxxxxxx> написал:
> >> >> >> > Hello!
> >> >> >> >
> >> >> >> > On Tue, Dec 10, 2013 at 05:16:45PM +0600, Илья Шипицин wrote:
> >> >> >> >
> >> >> >> >> 10 декабря 2013 г., 17:13 пользователь Maxim Dounin
> >> >> >> >> <mdounin@xxxxxxxxxx> написал:
> >> >> >> >> > Hello!
> >> >> >> >> >
> >> >> >> >> > On Tue, Dec 10, 2013 at 09:13:16AM +0600, Илья Шипицин wrote:
> >> >> >> >> >
> >> >> >> >> >> Добрый день!
> >> >> >> >> >>
> >> >> >> >> >> как-то уже писал на эту тему. дошли руки, выкатил патч в 
> >> >> >> >> >> продакшен.
> >> >> >> >> >> идея в том, что отправка заголовка "Connection: keep-alive" в
> >> >> >> >> >> большинстве случаев не нужна.
> >> >> >> >> >>
> >> >> >> >> >> абонентская база - сотни тысяч пользователей, сотни миллионов 
> >> >> >> >> >> запросов
> >> >> >> >> >> в месяц. думаю, спустя месяц-два можно будет считать, что все
> >> >> >> >> >> протестировано во всех возможных ситуациях.
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> желающие - приглашаются к тестированию.
> >> >> >> >> >>
> >> >> >> >> >> данное поведение "подсмотрено" у IIS, который по любым метрикам
> >> >> >> >> >> занимает десятки процентов "рынка":
> >> >> >> >> >> http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html
> >> >> >> >> >> - поэтому есть уверенность, что все обойдется без побочных 
> >> >> >> >> >> эффектов
> >> >> >> >> >
> >> >> >> >> > Илья, я вроде как сделал патч с таким поведением ещё в процессе
> >> >> >> >> > прошлого обсуждения:
> >> >> >> >> >
> >> >> >> >> > http://mailman.nginx.org/pipermail/nginx-ru/2013-May/051059.html
> >> >> >> >> >
> >> >> >> >> > Странно видить попытки изобрести велосипед заново вместо того,
> >> >> >> >> > чтобы заняться тестированием и последующим убеждением, что это
> >> >> >> >> > надо закоммитить, тем более про "тщательное тестирование" было
> >> >> >> >> > явно написано.  ;)
> >> >> >> >>
> >> >> >> >> это именно та тема и есть, сейчас дошли руки "тщательно
> >> >> >> >> протестировать". я запустил в продакшн.
> >> >> >> >
> >> >> >> > Меня в первую очередь удивило, что вместо патча, нарисованного ещё
> >> >> >> > полгода назад, к письму о "потестировать" прилагается совсем
> >> >> >> > другой патч, с чуть-чуть другими условиями и стилистическими
> >> >> >> > проблемами.  Я бы всё-таки рекомендовал тестировать то, что потом
> >> >> >> > будем коммитить.
> >> >> >> >
> >> >> >> >> ждем пару месяцев (и, если проблем не всплывает, считаем, что все 
> >> >> >> >> ок) ?
> >> >> >> >
> >> >> >> > Я, честно говоря, пребывал в надежде, что патч уже полгода
> >> >> >> > тестируется. ;)
> >> >> >> >
> >> >> >> > Но если нет - то, видимо, так и делаем.  Только просьба - взять
> >> >> >> > для тестирования патч в том виде, в каком его предполагается
> >> >> >> > коммитить, if any:
> >> >> >>
> >> >> >> без проблем. сегодня запущу в продакшн в таком виде
> >> >> >>
> >> >> >> не совсем понятно, зачем делать условие "r->http_version < 
> >> >> >> NGX_HTTP_VERSION_11"
> >> >> >> для версии 0.9, насколько я понимаю, и в моем и в вашем случае будет 
> >> >> >> фигня
> >> >> >
> >> >> > Для 0.9 всё это не будет выполняться, т.к. будет отсечено
> >> >> > проверкой
> >> >> >
> >> >> >     if (r->http_version < NGX_HTTP_VERSION_10) {
> >> >> >         return NGX_OK;
> >> >> >     }
> >> >> >
> >> >> > в начале функции.  Принципиальной разницы между патчами нет,
> >> >> > вопрос в основном стилистический (с учётом того, что между
> >> >> > HTTP/1.0 и HTTP/1.1 других версий быть не может).
> >> >>
> >> >> тогда получается, что мой вариант лучше.
> >> >>
> >> >> для 0.9 по RFC не бывает keep-alive
> >> >> для 1.0 у меня сравнение по равенству
> >> >
> >> > Не согласен, т.к. важно не то, что в HTTP/1.0 нет keepalive'а по
> >> > умолчанию, а то, что keepalive по умолчанию есть в HTTP/1.1 и
> >> > выше, а в версиях до HTTP/1.1 его нужно явно включать.
> >> >
> >> > В условиях, когда у нас есть только HTTP/1.0 и HTTP/1.1, и никаких
> >> > промежуточных версий быть не может - патчи эквивалентны, и
> >> > различие только стилистическое.  Но если бы был ещё какой-нибудь
> >> > HTTP/1.(1/2) - сравнение с HTTP/1.0 было бы неправильным.
> >>
> >> Максим, почему вы думаете, что разработчики RFC для HTTP/1.(1/2)
> >> заложат поведение, идентичное HTTP/1.0 ?
> >> ваш вариант это подразумевает. я не уверен, что будет именно так.
> >
> > Я уверен, что уже не будет.  Всмысле - никакой версии HTTP/1.(1/2)
> > никогда не будет.  Вопрос, повторяю, стилистический.
> 
> если вопрос стилистический, давайте остановимся на моей версии. она
> мне больше нравится

Да сколько угодно, я ж разве возражаю?  Только тогда патч не будет 
закоммичен из-за стилистических проблем.  ;)

> > Речь о том, что когда что-то меняется, то важна именно версия, в
> > которой это что-то поменялось.  Подход, предполагающий явное
> > перечисление - работает только в условиях малого количества
> > версий.  С ростом количества версий он становится непригодным к
> > использованию.
> 
> это как раз случай версий HTTP, их мало

Версий HTTP - потенциально бесконечное количество.  В nginx'е уже 
сейчас используются проверки r->http_version, нормально 
скалирующиеся при увеличении количества версий, проверяющие именно 
версии, в которых что-то изменилось.  См. например процитированный 
код выше.  Не надо это пытаться сломать.

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

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