On Sun, Apr 26, 2020 at 05:26:02PM +0200, Yann Ylavic wrote:
> For FILE buckets, the behaviour of apr_bucket_setaside() is to take
> *full* ownership of the underlying apr_file, that is: allocate/move
> the file/cleanup to the new pool AND set the old file's fd to -1 (see
> apr_file_setaside, [1]).
> 
> This can be problematic in an output filters chain whenever a FILE
> bucket gets splitted. Suppose that an FTYPE_RESOURCE output filter
> splits a FILE bucket in two and sends the first one through the chain,
> and then due to network congestion the core output filter needs to set
> the FILE bucket aside. It happens that the second FILE bucket becomes
> a dangling bucket (with fd == -1).

Hang on, I don't follow this, how does data->fd end up as -1 in this 
case?  The buckets split from the original FILE bucket have a common 
->data since it is a refcounted bucket type.  If any of them are 
setaside the common ->data->fd is replaced with a new apr_file_t 
allocated from a new (longer-lived) pool.  No?

> The case I'm facing is a bit different but similar. A handler is
> saving large bodies into a file and inserts an input filter for
> mod_proxy to use the file bucket as request body (much like
> mod_request). The file is still needed/used after mod_proxy (in an
> output filter), so I don't expect the file to be invalidated by
> mod_proxy's output filtering.

I do agree that it is surprising behaviour that the apr_file_t * is 
potentially invalidated after being wrapped in a FILE bucket though. Not 
sure how to avoid it, IIRC this is some optimisation to avoid excessive 
dup2() calls?

Regards, Joe

Reply via email to