Hello!

On Wed, Aug 28, 2013 at 05:54:39PM +0800, 邓尧 wrote:

> On Tue, Aug 27, 2013 at 10:21 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
>
> > Hello!
> >
> > On Tue, Aug 27, 2013 at 11:21:38AM +0800, 邓尧 wrote:
> >
> > > Hi,
> > > I'm writing an nginx module, it does something similar to the sub module.
> > > After some research I succeeded in handling the ngx_chain_t pointer
> > passed
> > > to my body filter. My module seems to work well for static files.
> > > When my module is handling PHP responses (fastcgi), sometimes the
> > > ngx_chain_t pointer is NULL. I simply call the next body filter in such
> > > situation like the sub module body filter. However function
> > > ngx_http_write_filter() will fail, because r->out isn't NULL
> > > and the buf's in r->out are of zero size.
> > > My questions are: what's the meaning of r->out? how should I modify it in
> > > my body filter ? Could I simply return NGX_OK in my body filter without
> > > calling the next body filter if the ngx_chain_t pointer is NULL ?
> >
> > The r->out is write filter's private data, you shouldn't touch it
> > in your module. And it shouldn't contain zero size non-special
> > buffers, if it does - there is a bug somewhere (most likely in
> > your filter).
>
> What are the most likely reasons for a buffer in r->out to be zero sized
> and non-special ? I do believe the bug is somewhere in my body filter, but
> I checked many times, cannot find it. My body filter's work flow is like
> the following:
> 1. create a private empty chain, ctx->out.
> 2. search the input chain for patterns
> 3. if a matched pattern is found, append three ngx_buf_t structures (one
> for the substitution string, two for the data surrounding the matched
> pattern) to ctx->out, the one used for the substitution string is zerorized
> then only three members are set: pos, last, memory. The other two are
> memcpy()ed from the original buffer then:
> * pos, last, file_pos, file_last are modified accordingly
> * last_buf, last_in_chain are cleared (last_buf & last_in_chain of the
> final chain are still set)
> * shadow is set to NULL
> 4. if no pattern is found, append the ngx_buf_t structure to ctx->out, then
> clear last_buf & last_in_chain.
> 5. when a pattern is across two buffers, well, it's ignored, should be no
> problem.
> 6. feed ctx->out to the next body filter
> 7. return the code from the above function call after some cleaning up.

I suspect your code reuses/modifies buffers passed to next body
filter before they are sent. Note you should keep track of
buffers passed to next filters and don't reuse them before they
are fully sent (usually ngx_chain_update_chains() function is used
for dirty work).

Alternatively, if you modify ngx_buf_t structures your code got
from previous body filters - your modifications may confuse
tracking code and buffers may be reused there (again, before they
are sent).

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel