ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello!

On Sat, May 16, 2009 at 03:21:44AM +0400, Kirill A. Korinskiy wrote:

> At Sat, 16 May 2009 00:07:19 +0400,
> Maxim Dounin <mdounin@xxxxxxxxxx> wrote:
> > 
> > Да, гоню.
> > 
> > А теперь внимание вопрос:
> > 
> > Если клиенты не умеют даже правильно посчитать message length 
> > при получении 204 - неужели ты думешь, что можно полагаться 
> > на корректное соблюдение ими этих отличий?
> > 
> 
> проблема в том что я сам не понимаю как правильно сообщать клиенту
> длину тела и считать ее ему.

Есть пункт 4.4. Message Length, который всё описывает.

> Т.е. я понимаю что:
> 
>  - не писать content-length валидно для запросов без тела

Да.  А писать - невалидно, причём "MUST NOT".

>  - игнорировать тело валидно для запросов у которого тела не может
>    быть. Т.е. его может послать сервер, например слова No Content ? но
>    их клиент должен игнорировать.

Угу.  Только если скажем в ответ на HEAD или у 204-го ответа 
вернули тело - это мусор в протоколе, и keepalive ушёл в лес.  
Единственное разумное действие клиента в данной ситуации - 
куда-нибудь выругаться и закрыть соединение.

> во всем этом бреде (я про http, ага) слишком много противоречий и как
> интерпретируют их авторы потенциального клиента ? не известно.
> 
> Все что я предлагаю ? это для перестраховки слать Content-Length: 0
> когда нет тела, что бы клиент который ждет тело длинной которой
> сказали или fin тоже остался доволен.

См. моё предыдущее письмо - это невалидно, и может иметь 
слабопредсказуемые последствия.

При текущем состоянии поддержки 204 в клиентах - использовать его 
можно только в строго контроллируемых условиях, при необходимости 
исправляя баги в клиентах.  Пытаться делать workaround'ы - себе 
дороже, и может выйти боком в самых неожиданных местах.

Maxim Dounin



 




Copyright © Lexa Software, 1996-2009.