You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by wr...@apache.org on 2002/08/04 20:24:11 UTC
cvs commit: httpd-2.0/modules/http http_protocol.c
wrowe 2002/08/04 11:24:10
Modified: modules/http http_protocol.c
Log:
Just an observation, we potentially read/retain far too much of the body,
and this can be optimized. Not a problem for sendfile based byterange
requests, but potentially lethal to serve byterange requests of any
parsed or cgi generated responses.
Revision Changes Path
1.452 +5 -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.451
retrieving revision 1.452
diff -u -r1.451 -r1.452
--- http_protocol.c 3 Aug 2002 19:36:33 -0000 1.451
+++ http_protocol.c 4 Aug 2002 18:24:10 -0000 1.452
@@ -2833,6 +2833,11 @@
/* We can't actually deal with byte-ranges until we have the whole brigade
* because the byte-ranges can be in any order, and according to the RFC,
* we SHOULD return the data in the same order it was requested.
+ *
+ * XXX: We really need to dump all bytes prior to the start of the earliest
+ * range, and only slurp up to the end of the latest range. By this we
+ * mean that we should peek-ahead at the lowest first byte of any range,
+ * and the highest last byte of any range.
*/
if (!APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(bb))) {
ap_save_brigade(f, &ctx->bb, &bb, r->pool);