httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: It's time to get 2.03-dev out
Date Sat, 12 Jun 2004 05:00:42 GMT
Scott Hutton <> writes:

> Joe Schaefer wrote:
> >Scott Hutton <> writes:
> >
> >[...]
> >
> >
> >>One more for the list.  At least as of RC2, the bug mentioned in:
> >>
> >>
> >>
> >>is still present.  I've been tracking it down.  I'm still testing
> >>against RC2 since I have it riddled with debugging code at this point,
> >>and no recent CVS commits seem to hit anything relevant to the bug.
> >>
> >
> >Thanks Scott, I've added the url to the BUGS section in the STATUS file.
> >
> FYI, for those few affected by the file-upload-over-SSL bug, I've
> located the problem, but don't have a fix yet.

The "quick" fix is to call apr_bucket_setaside() on all buckets that are
fetched via ap_get_brigade() in mod_apreq.c.  However I'd rather wait for a
future release for that, because getting it right will take some fleshing out.

> In mod_apreq.c:apreq_filter(), there appears to be a prefetch process
> going on. Repeated calls are made to pull in data via ap_get_brigade()
> (which populates a 'tmp' bucket brigade structure).  That structure is
> then "copied" using apreq_brigade_copy().  However, the 'data' element
> of the copied structures is being left intact (it's not a deep copy).
> As such, the next call to ap_get_brigade() with the original 'tmp'
> object in hand is causing portions of the original data to be overwritten.  

Yes and no.  Buckets are designed this way (shallow copy) to support
a zero-copy paradigm, there's other metadata in the buckets representing
the relevant data's offset and length.   The problem we're seeing with
SSL is that the buckets mod_ssl produces are transient (read
stack-allocated), so they must first be converted to heap-allocated
buckets to avoid the corruption you're witnessing firsthand.  That's what
apr_bucket_setaside is for, but we don't call it anywhere.  My bad, sorry.

Joe Schaefer

View raw message