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, [email protected] 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
