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.

Reply via email to