Same cached objects, but different body_bytes_sent

[Guilherme]

Thanks for your response, Zhang.

I included content-length in log_format to see:

y.y.y.y - [08/Jun/2017:22:15:46 +0000] "GET /image.jpg HTTP/2.0" 200 466
HIT "Mozilla/5.0 (Linux; Android 5.0.1; GT-I9515L Build/LRX22C)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.83 Mobile
Safari/537.36" 44 466 2.384 "image/jpeg" 21221
x.x.x.x - [08/Jun/2017:22:15:46 +0000] "GET /image.jpg HTTP/2.0" 200 21687
HIT "Mozilla/5.0 (Linux; Android 5.0; SM-G900F Build/LRX21T)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile
Safari/537.36" 41 21714 7.786 "image/jpeg" 21221

*log_format:* $remote_addr $remote_user [$time_local] "$request" $status
$body_bytes_sent $upstream_cache_status "$http_user_agent" $request_length
$bytes_sent $request_time "$sent_http_content_type"
$sent_http_content_length';

Any idea?


On Sat, Jun 3, 2017 at 10:47 AM, Zhang Chao <zchao1995 at gmail.com> wrote:

> Hi, Guilherme!
>
> The HTTP status code 499, which means client closed the connection before
> Nginx even sent one byte.
> As long as Nginx sent some bytes, 499 will not arise, and Nginx just
> record the code generated previously, also, i bet your log_format  of your
> access_log is the default one provided by Nginx, it is helpless when we
> need to speculate whether
> client closed the connection. Maybe you can modify your log_format such as
> appending “$http_content_length”, you can analysis this case by comparing
> the value of “$http_content_length” and “$body_bytes_sent”, of course the
> “Accept-Encoding” header can never be passed.
>
> On 3 June 2017 at 00:45:09, Guilherme (guilherme.e at gmail.com) wrote:
>
> @itpp2012:
>
> I cant replicate the problem using curl from 2 different locations.
>
> Its not supposed to return 206 in range requests?
>
> @zhang_chao:
>
> I'm not sure about this, but its not supposed to return 499 in this case?
>
> Tks,
>
> Guilherme
>
> On Fri, Jun 2, 2017 at 3:45 AM, Zhang Chao <zchao1995 at gmail.com> wrote:
>
>> Hi!
>>
>> Are you sure the client didn't close the connection when the body is
>> transferring?
>>
>>
>> On 2 June 2017 at 10:00:36, Guilherme (guilherme.e at gmail.com) wrote:
>>
>> I identified a strange behavior in my nginx/1.11.2. Same cached objects
>> are returning different content length. In the logs below, body_bytes_sent
>> changes intermittently between 215 and 3782 bytes. The correct length is
>> 3782. (these objects are not being updated in this interval)
>>
>> xxxxxxxxxx - - [02/Jun/2017:01:29:06 +0000] "GET
>> /img/app/bt_google_play.png HTTP/2.0" 200 *215* "xxxxxxxxxx"
>> "Mozilla/5.0 (Linux; Android 6.0.1; SM-G600FY Build/MMB29M)
>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.83 Mobile
>> Safari/537.36" 42 215 10.571 "image/png" HIT
>> xxxxxxxxxx - - [02/Jun/2017:01:29:50 +0000] "GET
>> /img/app/bt_google_play.png HTTP/2.0" 200 *3782* "xxxxxxxxxx"
>> "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X)
>> AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.0 Mobile/14F89
>> Safari/602.1" 32 3791 0.344 "image/png" HIT
>>
>> ** request_time is always high for the shorter requests*
>>
>> I'm ignoring Vary header in proxy_ignore_headers too.
>>
>> Any idea about this?
>>
>> Tks,
>>
>> Guilherme
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170608/02b55f52/attachment-0001.html>