Z_BUF_ERROR nginx 0.8.53

[Roman Vasilyev]

Hello,


Tested your patch, everything is fine, 2 hours my server working without 
any messages in log about deflate problems.

NGINX the best :)

Just in case want to ask about one variable, nginx have $host variable, 
but it using resolver, in my case I don't need it because I already have 
this info in NAT table (my traffic goes to nginx from rdr pf rule).
So the question is, what do you think about having var like $nat_ip 
which will get dest ip using
ioctl(dev, DIOCNATLOOK, &nl)? In my case it will decrease extra 
dependency from named.

On 11/18/2010 07:29 PM, Maxim Dounin wrote:
> Hello!
>
> On Thu, Nov 18, 2010 at 02:45:22PM -0800, Roman Vasilyev wrote:
>
>    
>> I've reproduced this problem with debuging.
>> Let me attach error log with debug, I'm not clearly understanding
>> nginx modules chain
>>      
> [...]
>
>    
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 http upstream process non
>> buffered upstream
>>      
> [...]
>
>    
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 http gunzip filter
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 gunzip in: 00000000055590E8
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 gunzip
>> in_buf:0000000005559108 ni:00000000012021A0 ai:10
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 inflate in:
>> ni:00000000012021A0 no:0000000005559940 ai:10 ao:4096 fl:2 redo:0
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 inflate out:
>> ni:00000000012021AA no:0000000005559940 ai:0 ao:4096 rc:0
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 gunzip
>> in_buf:0000000005559108 pos:00000000012021A0
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 http afbody in
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 http chunk size: 0
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 http afbody out
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 http postpone filter
>> "/?ar=1290119308" 00000000055590D8
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 http gzip filter
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 gzip in: 00000000055590C8
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 gzip
>> in_buf:0000000005559158 ni:0000000000000000 ai:0
>> 2010/11/18 14:42:23 [debug] 24622#0: *206 deflate in:
>> ni:0000000000000000 no:00000000056BDE20 ai:0 ao:8192 fl:2 redo:0
>> 2010/11/18 14:42:23 [alert] 24622#0: *206 deflate() failed: 2, -5
>> while reading upstream, client: 10.222.16.2, server: hss, request:
>> "GET /?ar=1290119308 HTTP/1.1", upstream:
>> "http://74.125.19.103:80/?ar=1290119308", host: "news.google.com",
>> referrer: "http://news.google.com/"
>>      
> Ah, ok, the problem is clear: due to use of proxy_buffered off;
> buffer had flush flag set.  All data from it was eaten by gunzip
> filter, and special flush buffer was passed along filter chain
> instead.
>
> The only way to reproduce this problem without third party modules
> (i.e. gunzip filter and your local modifications to it in your
> case) seems to use $r->flush() twice from embedded perl, see test
> case here:
>
> http://mdounin.ru/hg/nginx-tests/rev/e8546edb0267
>
> Correct patch to the problem attached.
>
> It basically lines up gzip filter to what is already done in
> gunzip filter - allows Z_BUF_ERROR as non-fatal and makes sure
> special flush buffer will be passed if there is no output in
> Z_SYNC_FLUSH case.
>
> Maxim Dounin
>    
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20101119/afac1c4b/attachment.html>