httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r1171250 - /httpd/httpd/trunk/modules/http/byterange_filter.c
Date Sat, 17 Sep 2011 15:14:33 GMT


On 09/17/2011 05:03 PM, Stefan Fritsch wrote:
> On Fri, 16 Sep 2011, Ruediger Pluem wrote:
>> On 09/15/2011 09:55 PM, sf@apache.org wrote:
>>> Author: sf
>>> Date: Thu Sep 15 19:55:27 2011
>>> New Revision: 1171250
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1171250&view=rev
>>> Log:
>>> use random value as multipart range boundary to prevent leaking
>>> information
>>> about the used MPM
>>>
>>> Modified:
>>>     httpd/httpd/trunk/modules/http/byterange_filter.c
>>>
>>> Modified: httpd/httpd/trunk/modules/http/byterange_filter.c
>>> URL:
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/byterange_filter.c?rev=1171250&r1=1171249&r2=1171250&view=diff
>>>
>>> ==============================================================================
>>>
>>> --- httpd/httpd/trunk/modules/http/byterange_filter.c (original)
>>> +++ httpd/httpd/trunk/modules/http/byterange_filter.c Thu Sep 15
>>> 19:55:27 2011
> 
>>> @@ -505,17 +504,15 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
>>>      if (num_ranges > 1) {
>>>          /* Is ap_make_content_type required here? */
>>>          const char *orig_ct = ap_make_content_type(r, r->content_type);
>>> -        boundary = apr_psprintf(r->pool, "%" APR_UINT64_T_HEX_FMT
>>> "%lx",
>>> -                                (apr_uint64_t)r->request_time, c->id);
>>>
>>>          ap_set_content_type(r, apr_pstrcat(r->pool, "multipart",
>>>                                             use_range_x(r) ? "/x-" :
>>> "/",
>>>                                             "byteranges; boundary=",
>>> -                                           boundary, NULL));
>>> +                                           ap_multipart_boundary,
>>> NULL));
>>
>> Isn't it an issue that we now always use the same boundary value?
> 
> I didn't see a reason why this would be a problem. Do you? The old
> boundary value was also rather predictable.

I don't know. My point was rather that it is predictable, but that it might
be needed to be different on each response. Protocol gurus, any idea?

Regards

RĂ¼diger

Mime
View raw message