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

[Kirill A. Korinskiy <catap+nginx@xxxxxxxx>]

At Sat, 16 May 2009 13:35:00 +0400,
Maxim Dounin <mdounin@xxxxxxxxxx> wrote:
> 
> 
> Нет способа узнать что тело *в данном ответе* будет 302 октета.  
> Потому как message length для таких ответов определён совершенно 
> однозначно, и не зависит от Content-Length и Transfer-Encoding.  
> Ибо они могут быть, а тела тем не менее в ответе не будет.
> 
> Соответственно - для 204 и т.п. завершаем чтение заголовков по 
> CRLF CRLF, если за этим что-то ещё есть - это ответ на следующий 
> запрос (привет pipelining) или просто мусор.
> 

угу, окончательно понял сей момент ? спасибо.

> > 
> > Я пока нашел один клиент с кривой поддержкой 204 - это wget. У
> > остальных оно идентичное ? так что не все так плохо.
> 
> Т.е. ты нам тут всё это рассказываешь чтобы патчи на wget не 
> сабмитить? :)
> 
> Но вообще - "потому что плохо искал" (c).
> 

скорее что бы самому понять донца семантику протокола. А патчи на wget
уже улетели в upstream, только, блин, пока они разойдутся по
дистрибутивам?

А у тебя есть еще клиенты на странное поведение? Я проверю! Давай
имена ;)

> > Проблема в том что мне нужно именно поведение 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.  :)
> 

ага ? именно то поведение которое я и хочу. Недияние.

Firefox и IE, кстати, ведут себя так же.

-- 
wbr, Kirill