You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2001/04/16 23:16:53 UTC
cvs commit: httpd-2.0/modules/http http_protocol.c
rbb 01/04/16 14:16:53
Modified: . CHANGES
modules/http http_protocol.c
Log:
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.
Submitted by: Graham Leggett <mi...@sharp.fm>
Revision Changes Path
1.176 +7 -0 httpd-2.0/CHANGES
Index: CHANGES
===================================================================
RCS file: /home/cvs/httpd-2.0/CHANGES,v
retrieving revision 1.175
retrieving revision 1.176
diff -u -d -b -w -u -r1.175 -r1.176
--- CHANGES 2001/04/14 21:11:09 1.175
+++ CHANGES 2001/04/16 21:16:52 1.176
@@ -1,5 +1,12 @@
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 <mi...@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).
1.313 +12 -0 httpd-2.0/modules/http/http_protocol.c
Index: http_protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.312
retrieving revision 1.313
diff -u -d -b -w -u -r1.312 -r1.313
--- http_protocol.c 2001/04/11 23:37:16 1.312
+++ http_protocol.c 2001/04/16 21:16:53 1.313
@@ -2347,6 +2347,18 @@
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).
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Apr 16, 2001 at 09:16:53PM -0000, rbb@apache.org wrote:
> rbb 01/04/16 14:16:53
>
> Modified: . CHANGES
> modules/http http_protocol.c
> Log:
> 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.
Actually, I just realized the mod_dav may also want to generate byteranges
(as it does today), rather than let the byterange filter do it.
"Why?" you may ask :-)
Consider the case where mod_dav fetches the content out of a database. We
don't want to fetch a full gigabyte, only to then have the byterange filter
trim out 10 bytes and send them to the client.
That said: with some redesign of the mod_dav backend APIs, I can create a
custom bucket that represents a mod_dav resource. Based on the byterange
filter's splits, copies, etc, followed by the final read, I should be able
to completely avoid reading in the whole gigabyte, yet still defer to the
byterange filter for processing.
(this would also handle the case of fetching a PHP script from a database,
processing it through the PHP filter, *then* yanking 10 bytes from the PHP
output)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/