Output filter is not finished

Adelino Monteiro adelino at ainou.net
Thu Aug 11 14:54:26 UTC 2011


I was just doing that but I found the module to be somehow complex and I
found no answers for it (again....)
See for instance this line that you can find trough out the file

    r->connection->buffered &= ~NGX_HTTP_GZIP_BUFFERED;

The r->connection->buffered is not used in the nginx core only in one other
modulel ngx_http_image_filter_module.c
Anyone know what this line influencing in the rest of the nginx
environment?

Regards,

AM

On 9 August 2011 19:17, Dave Bailey <dave at daveb.net> wrote:

> On Tue, Aug 9, 2011 at 11:00 AM, Adelino Monteiro <adelino at ainou.net>wrote:
>
>> Well since I got no response I suppose that I might have not expressed
>> myself properly.
>>
>> The problem is that I don't know howto tell nginx  that there is no
>> information and to go on with the next  request in the output buffer chain.
>> I looked at other modules and google around but couldn't find any
>> information that I could use.
>>
>
> I have found the gzip filter
> (src/http/modules/ngx_http_gzip_filter_module.c) to be a useful template for
> this.
>
> -dave
>
>
>>  Any help would be appreciated.
>>
>> AM
>>
>> On 8 August 2011 16:38, Adelino Monteiro <adelino at ainou.net> wrote:
>>
>>>
>>>
>>> Hello,
>>>
>>> I've build an output filter based on the guide from Evan Miller and some
>>> other modules.
>>>
>>> Everything has been working fine but lately I found that my
>>> next_body_filter call is returning NGX_AGAIN.
>>> This happens when I only have a very small  chain that won't get
>>> processed (I put in the ctx to process the next time), so the call to
>>>  ngx_http_next_body_filter(r, in)  basically don't has any output to
>>> process.
>>> Strangely I see that nginx put my request into a timer but what happens
>>> is that after that time the request is broken and the rest of the file don't
>>> get processed.
>>>
>>> Have a look at the output please:
>>>
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 http postpone filter "/u2.mp4?"
>>> 0000000001A02790
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 write new buf t:0 f:0
>>> 0000000000000000, pos 0000000001A0A56C, size: 5 file: 0, size: 0
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 write new buf t:1 f:0
>>> 0000000001A6ACB0, pos 0000000001A6ACB0, size: -5 file: 0, size: 0
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 http write filter: l:0 f:1 s:0
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 Save left_bytes [13] in context
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 http copy filter: -2 "/u2.mp4?"
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 http finalize request: -2,
>>> "/u2.mp4?" a:1, c:1
>>> 2011/08/08 15:45:41 [debug] 11461#0: *1 event timer add: 3:
>>> 60000:1312814801328
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 event timer del: 3: 1312814801328
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http run request: "/u2.mp4?"
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http writer handler: "/u2.mp4?"
>>> 2011/08/08 15:46:41 [info] 11461#0: *1 client timed out (110: Connection
>>> timed out) while sending mp4 to client, client: 192.168.56.1, server:
>>> localhost, request: "GET /u2.mp4 HTTP/1.1", host: "192.168.56.101:8080"
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http finalize request: 408,
>>> "/u2.mp4?" a:1, c:1
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http terminate request count:1
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http terminate cleanup count:1
>>> blk:0
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http posted request: "/u2.mp4?"
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http terminate handler count:1
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http request count:1 blk:0
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http close request
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 http log handler
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 run cleanup: 0000000001A0A290
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 file cleanup: fd:12
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000000000000
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000001A6ACB0
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000001A546C0
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000001A098C0, unused: 8
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000001A02680, unused:
>>> 3527
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 close http connection: 3
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 reusable connection: 0
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000001A094B0
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000001A08EB0
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 00000000019FDBE0, unused: 8
>>> 2011/08/08 15:46:41 [debug] 11461#0: *1 free: 0000000001A093A0, unused:
>>> 128
>>>
>>> My question is what magic do I need to do in order to tell Nginx that I
>>> don't have data to processe this time and to send me other content.
>>>
>>> I googled around and found some information from 2007 that told me to use
>>> timer but I can't find a example with that implementation and don't know if
>>> that is any longer supported.
>>>
>>> Any help is appreciated.
>>>
>>> AM
>>>
>>
>>
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20110811/3c37c1a1/attachment.html>


More information about the nginx-devel mailing list