Skip to content
  • Justin Erenkrantz's avatar
    Rewrite ap_byterange_filter so that it can work with data that does not · d4fcb4ca
    Justin Erenkrantz authored
    have a predetermined C-L - such as data that passes through mod_include.
    Previously, these requests would generate 416 since when the byterange
    filter ran, r->clength would be 0.  r->clength is only guaranteed to
    be valid after C-L filter is run, but we need C-L to run after us so
    that our data can have a proper C-L returned.  So, we need to rearrange
    the code so that we can deal with this case.
    
    Highlights:
    - Remove r->boundary since it is possible to have this self-contained in
      boundary's ctx.  (May require MMN bump?)
    - Remove call to parse_byteranges in ap_set_byterange since this would
      wrongly return -1 for dynamic responses.  We have to wait until we
      see EOS to call parse_byteranges.
    - Move bound_head computation inside the num_parts == 2 check.
    - Change a NULL brigade check to APR_BRIGADE_EMPTY
    - Move the 416 error return to after we've run through all ranges and
      found none of them to be valid.
    
    
    git-svn-id: https://svn.a...
    d4fcb4ca
To find the state of this project's repository at the time of any of these versions, check out the tags.