httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Hutton <shut...@sputnik.com>
Subject Re: It's time to get 2.03-dev out
Date Sat, 12 Jun 2004 04:27:31 GMT
Joe Schaefer wrote:

>Scott Hutton <shutton@sputnik.com> writes:
>
>[...]
>
>  
>
>>One more for the list.  At least as of RC2, the bug mentioned in:
>>
>>    http://marc.theaimsgroup.com/?l=apreq-dev&m=108609005217749&w=2
>>
>>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.

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.  You end up with a growing list of buckets that all point 
to the same char *, which makes for some wacky results.

I'm still plodding through the bucket brigade and related API's to 
figure the right way to fix this.  However, maybe some of that will ring 
a bell with someone (i.e., the writer of apreq_filter() and 
apreq_brigade_copy()). I think there may be something one is expected to 
do with the results received from ap_get_brigade() if one plans to keep 
the data around.  Perhaps mod_ssl reuses the buffer, and that's a legal 
behavior?

 -Scott

Mime
View raw message