ПРОЕКТЫ 


  АРХИВ 


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: zero size reply (200 0 в л огах)



Hello!

On Wed, Aug 26, 2009 at 12:49:48AM +0400, Alexander Azarov wrote:

> 25.08.2009, в 22:49, Maxim Dounin написал(а):
>
>> On Tue, Aug 25, 2009 at 08:59:20PM +0400, Alexander Azarov wrote:
>>
>>> Наблюдаю записи в логах со статусом 200 и размером ответа 0. При
>>> рассмотрении debug лога обнаружилось две странности. Первая:
>>>
>>> 2009/08/25 20:13:16 [info] 17099#0: *1338651 client closed  
>>> prematurely
>>> connection, so upstream conne
>>> ction is closed too while sending request to upstream, client:
>>> 66.249.65.86, server: ***,
>>> request: "GET /forum-52 HTTP/1.1", subrequest: "/news.html", u
>>> pstream: "fastcgi://127.0.0.1:9004", host: "***"
>>> 2009/08/25 20:13:16 [debug] 17099#0: *1338651 finalize http upstream
>>> request: 499
>>>
>>> /news.html это SSI вставка. Клиент закрыл соединение, это ОК. Должен 
>>> был
>>> бы получиться статус 499 и он таковой для подзапроса, однако у  
>>> запроса в
>>> логе 200. Это баг или фича? Можно ли как-то в логе получить 499?
>>
>> Заголовки ответа на основной запрос уходят раньше, чем начинает
>> работать SSI.  Именно код ответа из этих заголовков (т.е. отданный
>> клиенту) логгируется.
>>
>> Точно так же для обычного ответа клиент может закрыть соединение
>> раньше, чем получит весь ответ.  В этом случае будет код 200 - но
>> по размеру отданного будет видно, что клиент забрал не всё.
>>
>> 499 в логе будет только если клиент закрыл соединение до того, как
>> ему отправили заголовки.
>
> Понял, спасибо. А есть ли какая-то волшебная переменная, которую можно  
> записать в лог, из значения которой было бы понятно, что клиент сам  
> закрыл соединение. Я всегда смотрел на 499, но он покрывает не все  
> случаи, как теперь понятно.

Именно "сам закрыл" - нет.

Есть $request_completion, но и оно тоже покрывает не все случаи - 
ответ мог полностью уйти в исходящие буфера сокета, и что с ним 
было дальше - nginx не узнает.

Maxim Dounin



 




Copyright © Lexa Software, 1996-2009.