request, then the byterange filter should not try to redo the
work. The most common case of this happening, is a byterange
request going through the proxy, and the origin server handles
the byterange request. The proxy should ignore it.
Submitted by: Graham Leggett <minfrin@sharp.fm>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88873
13f79535-47bb-0310-9956-
ffa450edef68
Changes with Apache 2.0.17-dev
+ *) If a higher-level filter handles the the byterange aspects of a
+ request, then the byterange filter should not try to redo the
+ work. The most common case of this happening, is a byterange
+ request going through the proxy, and the origin server handles
+ the byterange request. The proxy should ignore it.
+ [Graham Leggett <minfrin@sharp.fm>]
+
*) Changed the threaded mpm to have child_main join to each of the
worker threads to make sure the kids are all gone before child_main
exits after a signal (cleanup from perform_idle_server_maintenance).
if (r->assbackwards)
return 0;
+ /* is content already a single range? */
+ if (apr_table_get(r->headers_out, "Content-Range")) {
+ return 0;
+ }
+
+ /* is content already a multiple range? */
+ if ((ct = apr_table_get(r->headers_out, "Content-Type")) &&
+ (!strncasecmp(ct, "multipart/byteranges", 20) ||
+ !strncasecmp(ct, "multipart/x-byteranges", 22))) {
+ return 0;
+ }
+
/* Check for Range request-header (HTTP/1.1) or Request-Range for
* backwards-compatibility with second-draft Luotonen/Franks
* byte-ranges (e.g. Netscape Navigator 2-3).