Working [Patch 1.3.15] byteranges no longer broken :-)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Here it is... forgot we needed to compute some indirected start/len,
and somewhere the code was confused between lengths and ends.  Got it
all working.  The infinate loops may have caught me off guard yesterday,
since a stray apache process may have tried and served the pages I was
seeing with c-l errors.

There is a caviat, we don't seem to watch out for ';' ending of the
Range:bytes= tag, I don't think we did before, I don't know if we expect 
';'s, and I'm not certain which code is responsible to rip it off the end.

So here is the patch, ignoring the ';' question, we do more than we did, 
and do it right.  I'm +1 on this one, tested it myself.  Jim, Tony, anyone 
else willing to try and break it?

Bill

Oh, one other odd condition, if you pass Range:bytes=
with no ranges at all, which is it?  Empty ranges are syntactially valid,
so there is no satisfiable range.  We would 416, but is that right?

> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Sunday, December 17, 2000 9:30 AM
> To: new-httpd@apache.org
> Subject: [Patch 1.3.15] byteranges still broken on 1.3+2.0
> 
> 
> The patch had a small infinite loop (wasn't checking that we still
> had *range contents) and some typos in comments (skip s/dash/comma)...
> new patch attached.
> 
> But it's more serious... this is the response that I get for 
> a query of 
> Range:bytes=10-20,30-40;
> 
> HTTP/1.1 206 Partial Content
> Date: Sun, 17 Dec 2000 15:02:46 GMT
> Server: Apache/1.3.15-dev (Win32)
> Content-Location: index.html.en
> Vary: negotiate,accept-language,accept-charset
> TCN: choice
> Last-Modified: Fri, 15 Dec 2000 17:24:31 GMT
> ETag: "0-570-3a3a53cf;3a3a553e"
> Accept-Ranges: bytes
> Content-Type: multipart/byteranges; boundary=3a3cd596414
> Content-Language: en
> 
> 
> --3a3cd596414
> Content-type: text/html
> Content-range: bytes 10-20/1392
> 
> HTML PUBLIC
> --3a3cd596414
> Content-type: text/html
> Content-range: bytes 30-40/1392
> 
> /DTD HTML 3
> --3a3cd596414--
> 
> The Content-Length needs to include the length of the boundries
> and embedded tags, correct?  And so the 1.3.15, at least, should
> already do so.  Some code wipes our content-length we already set,
> or we aren't setting it in enough places.
> 
> Can't research till tonight, feel free to jump ahead of me.
> 
> Bill

RE: Clean [Patch 1.3.15] byteranges no longer broken :-)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Sunday, December 17, 2000 12:54 PM
>
> There is a caviat, we don't seem to watch out for ';' ending of the
> Range:bytes= tag, I don't think we did before, I don't know if we expect 
> ';'s, and I'm not certain which code is responsible to rip it off the end.
> 
> So here is the patch, ignoring the ';' question, we do more than we did, 
> and do it right.  I'm +1 on this one, tested it myself.  Jim, Tony, anyone 
> else willing to try and break it?

Since nobody has taken the time to look at this... here is the proper patch
including the ; exception.
 
> Oh, one other odd condition, if you pass Range:bytes= with no ranges at 
> all, which is it?  Empty ranges are syntactially valid, so there is no 
> satisfiable range.  We would 416, but is that right?

Since nobody took up the challenge to extract this concept from the docs,
I've gone back and decided we must have a quad state - valid(1), legal but 
unsatisfiable (0, past the end, legally empty(-1), and invalid syntax (-2).

According to the rfc2616, one white duck=nothing at all (oh, wait, that must
have been Jethro Tull... hold on...) an 'empty' item in a set doesn't count
to satify the 'one or more' elements of a set requirement.  Ergo, bytes=,,,
means absolutely nothing, while bytes=,,0-,, means one thing (the whole thing).

So this patch addresses that issue as well.  Happy proofreading.