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 20ad5f2c00e394631b5f9e8484ede65246dfb944..d4a28f996e1825a0c6945660504c8768e5eb2cdf 100644 (file)
--- 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);