Problem with content length filter

[Brian Havard <br...@kheldar.apana.org.au>]

I'm seeing a problem where I'm getting a 0 length body & have traced the
sequence of events to:

- default_handler opens the file to be sent & calls ap_send_fd
- ap_send_fd passes a brigade containing a file bucket
- ap_content_length_filter sets the brigade aside & returns
- default_handler closes the file
...
- core_output_filter tries to send the file but gets nothing because the
handle is already closed.

My first hunch is that default_handler shouldn't close the handle, leaving
it to the file bucket's destructor or the pool cleanup. Alternatively
either the file bucket create or set-aside could dupe the handle.

Comments?

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------

Re: Problem with content length filter

[rb...@covalent.net]

> ARGH!  The default handler is still using ap_send_fd, which means it can't
> attach the EOS bucket.  This handler should be re-written to use buckets
> directly, because we always know this will just be sending a simple file,
> and we can avoid multiple trips down the stack if it just attaches the
> EOS.  It also tells the content-length filter to always set the
> content-length if we just have a simple file to send.

One more thing I just noticed.  This handler should also not be setting
the content-length itself.  There is a real chance that the data in the
file will be modified, and we have the content-length filter to set the
C-L, so no handler should really bother doing it.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Problem with content length filter

[rb...@covalent.net]

On Sun, 12 Nov 2000 rbb@covalent.net wrote:
>
> > My first hunch is that default_handler shouldn't close the handle,
leaving
> > it to the file bucket's destructor or the pool cleanup. Alternatively
> > either the file bucket create or set-aside could dupe the handle.
> 
> Your first hunch is 100% correct.  The default handler shouldn't ever
> close anything.  Also, please make sure the default handler is allocating
> the file out of the connections pool.  Otherwise, we won't be able to save
> the file.  Also, the default handler should be attaching an EOS bucket at
> the end of the brigade, because that will keep the content-length filter
> from even bothering to save the brigade aside.

ARGH!  The default handler is still using ap_send_fd, which means it can't
attach the EOS bucket.  This handler should be re-written to use buckets
directly, because we always know this will just be sending a simple file,
and we can avoid multiple trips down the stack if it just attaches the
EOS.  It also tells the content-length filter to always set the
content-length if we just have a simple file to send.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Problem with content length filter

[rb...@covalent.net]

On Sun, 12 Nov 2000, Brian Havard wrote:

> I'm seeing a problem where I'm getting a 0 length body & have traced the
> sequence of events to:
> 
> - default_handler opens the file to be sent & calls ap_send_fd
> - ap_send_fd passes a brigade containing a file bucket
> - ap_content_length_filter sets the brigade aside & returns
> - default_handler closes the file
> ...
> - core_output_filter tries to send the file but gets nothing because the
> handle is already closed.
> 
> My first hunch is that default_handler shouldn't close the handle, leaving
> it to the file bucket's destructor or the pool cleanup. Alternatively
> either the file bucket create or set-aside could dupe the handle.

Your first hunch is 100% correct.  The default handler shouldn't ever
close anything.  Also, please make sure the default handler is allocating
the file out of the connections pool.  Otherwise, we won't be able to save
the file.  Also, the default handler should be attaching an EOS bucket at
the end of the brigade, because that will keep the content-length filter
from even bothering to save the brigade aside.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

RE: Problem with content length filter

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Sunday, November 12, 2000 2:36 AM
> 
> I'm seeing a problem where I'm getting a 0 length body & have 
> traced the
> sequence of events to:
> 
> - default_handler opens the file to be sent & calls ap_send_fd
> - ap_send_fd passes a brigade containing a file bucket
> - ap_content_length_filter sets the brigade aside & returns
> - default_handler closes the file
> ...
> - core_output_filter tries to send the file but gets nothing 
> because the
> handle is already closed.
> 
> My first hunch is that default_handler shouldn't close the 
> handle, leaving
> it to the file bucket's destructor or the pool cleanup. Alternatively
> either the file bucket create or set-aside could dupe the handle.
> 
> Comments?

Do we need to start refcounting apr_open / apr_close?