From: William A. Rowe Jr <wrowe@apache.org>
Date: Sun, 4 Aug 2002 18:24:10 +0000 (+0000)
Subject:   Just an observation, we potentially read/retain far too much of the body,
X-Git-Tag: 2.0.40~24
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=26e0cc6f6dc0477c0f5e8b5d4ea22eb0111b1edc;p=apache

  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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96304 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/modules/http/http_protocol.c b/modules/http/http_protocol.c
index 20ad5f2c00..d4a28f996e 100644
--- a/modules/http/http_protocol.c
+++ b/modules/http/http_protocol.c
@@ -2833,6 +2833,11 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_byterange_filter(ap_filter_t *f,
     /* 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);