You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ruediger Pluem <rp...@apache.org> on 2011/09/16 17:12:54 UTC
Re: svn commit: r1171250 - /httpd/httpd/trunk/modules/http/byterange_filter.c
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
> @@ -442,7 +442,6 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
> apr_status_t rv;
> int found = 0;
> int num_ranges;
> - char *boundary = NULL;
> char *bound_head = NULL;
> apr_array_header_t *indexes;
> indexes_t *idx;
> @@ -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?
Regards
Rüdiger
Re: svn commit: r1171250 - /httpd/httpd/trunk/modules/http/byterange_filter.c
Posted by Ruediger Pluem <rp...@apache.org>.
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
Re: svn commit: r1171250 -
/httpd/httpd/trunk/modules/http/byterange_filter.c
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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.