Usage of the shadow field in ngx_buf_t?

[Igor Sysoev]

On Thu, Dec 03, 2009 at 03:13:00PM -0800, Brian Pane wrote:

> On Thu, Dec 3, 2009 at 1:21 PM, Igor Sysoev <igor at sysoev.ru> wrote:
> 
> > On Thu, Dec 03, 2009 at 12:08:29PM -0800, Brian Pane wrote:
> >
> > > Can someone explain (or point me to some documentation on) the meaning of
> > > the shadow field in ngx_buf_t?
> >
> > This is ancient thing and I do not like it. It was initially introduced
> > in code used by proxy and fastcgi to bookkeeping buf's saved in temporary
> > files. But now I think this is overengineered thing. Then it also used
> > to bookkeeping in SSI filter. Probably, it should rwritten, too.
> >
> > > I'm writing a body filter, and I'm trying to
> > > figure out whether the presence of a non-null shadow in a buffer means
> > that
> > > I need to do any special processing.
> >
> > No.
> 
> 
> Thanks.  A follow-up question: When a body filter is processing buffers that
> were produced by the proxy module (i.e., buffers containing an HTTP response
> from a back-end server), is it safe to discard those buffers?
> 
> As a trivial example, imagine that you have a body filter that simply
> returns NGX_OK, in order to prevent the response body from being
> sent to the client. Is that a safe thing to do?  Or is it necessary to
> pass the buffers through to the standard filters?  It's not clear to me
> whether anything in the standard filter chain needs to see the buffers
> containing the upstream response in order to do cleanup or flow control.

As it was already said, you should mark a buf as consumed:

   buf->pos = buf->last;

There are two filters that do not pass the orignal buf's to a client at all:

ngx_http_xslt_filter_module
ngx_http_image_filter_module

Even more: they postpone header sending until whole body will have
been processed.


-- 
Igor Sysoev
http://sysoev.ru/en/