Выставлять connection close

[Maxim Dounin]

Hello!

On Sat, May 16, 2009 at 04:29:09AM +0400, Kirill A. Korinskiy wrote:

> At Sat, 16 May 2009 04:13:49 +0400,
> Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > > Т.е. я понимаю что:
> > > 
> > >  - не писать content-length валидно для запросов без тела
> > 
> > Да.  А писать - невалидно, причём "MUST NOT".
> > 
> 
> А есть ли разница между не имеет тело и имеет нулевой длины?

А есть ли мальчик?

> > >  - игнорировать тело валидно для запросов у которого тела не может
> > >    быть. Т.е. его может послать сервер, например слова No Content — но
> > >    их клиент должен игнорировать.
> > 
> > Угу.  Только если скажем в ответ на HEAD или у 204-го ответа 
> > вернули тело - это мусор в протоколе, и keepalive ушёл в лес.  
> > Единственное разумное действие клиента в данной ситуации - 
> > куда-нибудь выругаться и закрыть соединение.
> > 
> 
> Но если клиенту сказали что тело будет 302 октета, и их передали —
> хотя их там быть не должно — клиент должен тело проигнорировать. Я не
> думаю что это мусор, ага?

Нет способа узнать что тело *в данном ответе* будет 302 октета.  
Потому как message length для таких ответов определён совершенно 
однозначно, и не зависит от Content-Length и Transfer-Encoding.  
Ибо они могут быть, а тела тем не менее в ответе не будет.

Соответственно - для 204 и т.п. завершаем чтение заголовков по 
CRLF CRLF, если за этим что-то ещё есть - это ответ на следующий 
запрос (привет pipelining) или просто мусор.

> > > во всем этом бреде (я про http, ага) слишком много противоречий и как
> > > интерпретируют их авторы потенциального клиента — не известно.
> > > 
> > > Все что я предлагаю — это для перестраховки слать Content-Length: 0
> > > когда нет тела, что бы клиент который ждет тело длинной которой
> > > сказали или fin тоже остался доволен.
> > 
> > См. моё предыдущее письмо - это невалидно, и может иметь 
> > слабопредсказуемые последствия.
> > 
> > При текущем состоянии поддержки 204 в клиентах - использовать его 
> > можно только в строго контроллируемых условиях, при необходимости 
> > исправляя баги в клиентах.  Пытаться делать workaround'ы - себе 
> > дороже, и может выйти боком в самых неожиданных местах.
> > 
> 
> Я пока нашел один клиент с кривой поддержкой 204 - это wget. У
> остальных оно идентичное — так что не все так плохо.

Т.е. ты нам тут всё это рассказываешь чтобы патчи на wget не 
сабмитить? :)

Но вообще - "потому что плохо искал" (c).

> Проблема в том что мне нужно именно поведение No Content.

Я тут проверил что 204 делает с Google Chrome - так он абзац

   If the client is a user agent, it SHOULD NOT change its document view
   from that which caused the request to be sent.

трактует абсолютно буквально.  Т.е. не меняет document view 
после получения 204.  Вообще.  Т.е. вводишь в адресной строке очередной 
адрес - а в ответ тишина...  Правда, если в document view были 
ссылки, то переходы по ним срабатывают.  Непорядок.  :)

Я правильно понимаю - что это именно то поведение которое тебя 
устраивает?  Полностью соответствует RFC IMHO.  :)

Maxim Dounin