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

[Илья Шипицин <chipitsine@xxxxxxxxx>]

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 ?
ваш вариант это подразумевает. я не уверен, что будет именно так.

я могу обосновать, что выпуск промежуточной версии между 1.0 и 1.1
означает, что разработчики RFC попрощались с здравым смыслом.
и в этом случае делать предположения опасно.


на данный момент определено поведение keep-alive для версий

0.9 (отсутствует как класс)
1.0 (необходим явный хедер Connection: keep-alive)
1.1 (в некоторых случаях хедер можно опустить)

я предлагаю не вводить пользователь в заблуждение сравнение "<" с
вытекающим возможным побочным эффектом, если
вдруг промежуточная версия между 1.0 и 1.1 появится и будет себя
особым образом вести

>
> (И таки да, не бывает keepalive'а в HTTP/0.9 потому, что там нет
> заголовков.  Если бы они были - никто не мешает и там быть
> keepalive'у - если о нём договорились, аналогично соответствующей
> процедуре в HTTP/1.0.)
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru