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);