You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2001/01/16 01:39:26 UTC
1.3.15 byte ranges
I'd like to propose that the patch be commited and the review process
and test be done on the 1.3.15 tree with it in place. Basically,
C-T-R
I think we'll get a better peer review.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"Casanova will have many weapons; To beat him you will
have to have more than forks and flatulence."
Re: 1.3.15 byte ranges
Posted by Tony Finch <do...@dotat.at>.
Jeff Trawick <tr...@bellsouth.net> wrote:
>dumb question: has an invalid range always resulted in the entire
>object being delivered? (well, pretty obvious from the code but it
>was surprising to me!)
RFC 2616 sect. 14.35
If the last-byte-pos value is present, it MUST be greater than or
equal to the first-byte-pos in that byte-range-spec, or the byte-
range-spec is syntactically invalid. The recipient of a byte-range-
set that includes one or more syntactically invalid byte-range-spec
values MUST ignore the header field that includes that byte-range-
set.
>I've played with the "current" code a bit on Linux and OS/390, mostly
>with the Adobe Acrobat plug-in as the client... no problems found, of
>course... the code looks better too, which doesn't hurt (though I'd
>prefer to see "r->range = NULL;" instead of "r->range = 0;" :) )
Good suggestion.
I'll commit the new version now, but I'll leave the showstopper
designation in the STATUS file because I've received a report of
problems from a user. I'll try and get this cleared up soon.
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"Then they attacked a town. A small town, I'll admit.
But nevertheless a town of people. People who died."
Re: 1.3.15 byte ranges
Posted by Jeff Trawick <tr...@bellsouth.net>.
dumb question: has an invalid range always resulted in the entire
object being delivered? (well, pretty obvious from the code but it
was surprising to me!)
I've played with the "current" code a bit on Linux and OS/390, mostly
with the Adobe Acrobat plug-in as the client... no problems found, of
course... the code looks better too, which doesn't hurt (though I'd
prefer to see "r->range = NULL;" instead of "r->range = 0;" :) )
I'll update the status file with my +1.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 1.3.15 byte ranges
Posted by Tony Finch <do...@dotat.at>.
Paul Marquis <pm...@pobox.com> wrote:
>For multiple byte ranges, it seems Apache inserts an extra CR/LF
>before the first range separator is printed. Is this a problem or am
>I being pedantic?
This turns out not to be a problem. See section 19.2 of RFC 2616:
1) Additional CRLFs may precede the first boundary string in the
entity.
(this is related to the optional preamble and epilogue sections in a
MIME multipart message)
And it's a complete bugger to avoid sending them so I think the code
can stay as it is.
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"And remember my friend, future events such
as these will affect you in the future."
Re: 1.3.15 byte ranges
Posted by Tony Finch <do...@dotat.at>.
Tony Finch <do...@dotat.at> wrote:
>
>Gnu wget uses Range: headers to resume partial downloads, but it
>doesn't give the server nearly so much of a workout as Acrobat, and
>it is harder to use for testing this feature.
And it only asks for one range at a time and therefore doesn't grok
multipart/byterages because it doesn't need to, except for buggy web
servers. "A response to a request for a single range MUST NOT be sent
using the multipart/byteranges media type."
/* #### Gag me! Some servers (e.g. WebSitePro) have been known
to misinterpret the following `Range' format, and return the
document as multipart/x-byte-ranges MIME type!
#### TODO: Interpret MIME types, recognize bullshits similar
the one described above, and deal with them! */
sprintf (range, "Range: bytes=%ld-\r\n", hs->restval);
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"Well, as long as they can think we'll have our problems.
But those whom we're using cannot think."
Re: 1.3.15 byte ranges
Posted by Tony Finch <do...@dotat.at>.
Paul Marquis <pm...@pobox.com> wrote:
>
>In byterange_boundary(), the boundary is always prefix by a CR/LF, but
>for the first boundary it's not necessary, as there's no previous
>range to separate. I, unfortunately, don't know how to best patch the
>problem.
I'm working something out.
This bug was inherited from earlier versions of Apache, so it has been
around for a while. See the packet dump from 1.3.12 below, in
particular the 0d0a 0d0a 0d0a at offset 0x01d4.
>FWIW, all my tests with Acrobat work just fine with this "bug". Are
>there any other common clients that use byte ranges?
I'd like to know as well :-) Gnu wget uses Range: headers to resume
partial downloads, but it doesn't give the server nearly so much of a
workout as Acrobat, and it is harder to use for testing this feature.
>Again, apologies for being a pedant (I can thank gcc for that
>vocabulary word).
No, pedants are good :-)
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"You realize there's a government directive stating
that there is no such thing as a flying saucer?"
22:09:26.332969 dyn-35.sfo.covalent.net.http > dyn-66.sfo.covalent.net.1654: . 550:2010(1460) ack 1001 win
0x0000 4500 05dc 4c0b 4000 4006 d4ac 0a00 0023 E...L.@.@......#
0x0010 0a00 0042 0050 0676 335d e2d3 64ec f55d ...B.P.v3]..d..]
0x0020 5010 4470 6497 0000 4854 5450 2f31 2e31 P.Dpd...HTTP/1.1
0x0030 2032 3036 2050 6172 7469 616c 2043 6f6e .206.Partial.Con
0x0040 7465 6e74 0d0a 4461 7465 3a20 4672 692c tent..Date:.Fri,
0x0050 2031 3920 4a61 6e20 3230 3031 2032 323a .19.Jan.2001.22:
0x0060 3039 3a32 3620 474d 540d 0a53 6572 7665 09:26.GMT..Serve
0x0070 723a 2041 7061 6368 652f 312e 332e 3132 r:.Apache/1.3.12
0x0080 2028 556e 6978 290d 0a4c 6173 742d 4d6f .(Unix)..Last-Mo
0x0090 6469 6669 6564 3a20 4672 692c 2031 3920 dified:.Fri,.19.
0x00a0 4a61 6e20 3230 3031 2032 323a 3033 3a30 Jan.2001.22:03:0
0x00b0 3220 474d 540d 0a45 5461 673a 2022 3230 2.GMT..ETag:."20
0x00c0 3838 332d 3334 6366 332d 3361 3638 6239 883-34cf3-3a68b9
0x00d0 3936 220d 0a41 6363 6570 742d 5261 6e67 96"..Accept-Rang
0x00e0 6573 3a20 6279 7465 730d 0a43 6f6e 7465 es:.bytes..Conte
0x00f0 6e74 2d4c 656e 6774 683a 2033 3033 3235 nt-Length:.30325
0x0100 0d0a 4b65 6570 2d41 6c69 7665 3a20 7469 ..Keep-Alive:.ti
0x0110 6d65 6f75 743d 3330 302c 206d 6178 3d39 meout=300,.max=9
0x0120 390d 0a43 6f6e 6e65 6374 696f 6e3a 204b 9..Connection:.K
0x0130 6565 702d 416c 6976 650d 0a43 6f6e 7465 eep-Alive..Conte
0x0140 6e74 2d54 7970 653a 206d 756c 7469 7061 nt-Type:.multipa
0x0150 7274 2f78 2d62 7974 6572 616e 6765 733b rt/x-byteranges;
0x0160 2062 6f75 6e64 6172 793d 3361 3638 6262 .boundary=3a68bb
0x0170 3136 6639 6330 0d0a 0d0a 0d0a 2d2d 3361 16f9c0......--3a
0x0180 3638 6262 3136 6639 6330 0d0a 436f 6e74 68bb16f9c0..Cont
0x0190 656e 742d 7479 7065 3a20 6170 706c 6963 ent-type:.applic
0x01a0 6174 696f 6e2f 7064 660d 0a43 6f6e 7465 ation/pdf..Conte
0x01b0 6e74 2d72 616e 6765 3a20 6279 7465 7320 nt-range:.bytes.
0x01c0 3231 3434 3239 2d32 3135 3437 322f 3231 214429-215472/21
0x01d0 3633 3037 0d0a 0d0a 0d30 3030 3030 3030 6307.....0000000
Re: 1.3.15 byte ranges
Posted by Paul Marquis <pm...@pobox.com>.
I think I found the problem (if you consider this a problem):
In byterange_boundary(), the boundary is always prefix by a CR/LF, but
for the first boundary it's not necessary, as there's no previous
range to separate. I, unfortunately, don't know how to best patch the
problem.
FWIW, all my tests with Acrobat work just fine with this "bug". Are
there any other common clients that use byte ranges?
Again, apologies for being a pedant (I can thank gcc for that
vocabulary word).
Tony Finch wrote:
> Paul Marquis <pm...@pobox.com> wrote:
> >For multiple byte ranges, it seems Apache inserts an extra CR/LF
> >before the first range separator is printed. Is this a problem or
> >am I being pedantic? The Content-Length has this extra CR/LF
> >factored into its total.
>
> Thanks for the report; I'll investigate.
>
> >The sample in the HTTP/1.1 spec (RFC 2616) doesn't have it and,
> >FWIW, neither does IIS 4.0 (strangely, IIS sets the Content-Type
> >to multipart/x-byteranges).
>
> That's the old spelling of the content type, which Apache also
> uses for old user agents.
--
Paul Marquis
pmarquis@pobox.com
Re: 1.3.15 byte ranges
Posted by Tony Finch <do...@dotat.at>.
Paul Marquis <pm...@pobox.com> wrote:
>For multiple byte ranges, it seems Apache inserts an extra CR/LF
>before the first range separator is printed. Is this a problem or am
>I being pedantic? The Content-Length has this extra CR/LF factored
>into its total.
Thanks for the report; I'll investigate.
>The sample in the HTTP/1.1 spec (RFC 2616) doesn't have it and, FWIW,
>neither does IIS 4.0 (strangely, IIS sets the Content-Type to
>multipart/x-byteranges).
That's the old spelling of the content type, which Apache also uses
for old user agents.
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"Perhaps on your way home you will pass someone in the dark,
and you will never know it, for they will be from outer space."
Re: 1.3.15 byte ranges
Posted by Paul Marquis <pm...@pobox.com>.
For multiple byte ranges, it seems Apache inserts an extra CR/LF
before the first range separator is printed. Is this a problem or am
I being pedantic? The Content-Length has this extra CR/LF factored
into its total.
The sample in the HTTP/1.1 spec (RFC 2616) doesn't have it and, FWIW,
neither does IIS 4.0 (strangely, IIS sets the Content-Type to
multipart/x-byteranges).
This is testing against a patched 1.3.14, using the patch specified
below.
Tony Finch wrote:
> Bill Stoddard <bi...@wstoddard.com> wrote:
> >
> >It looks okay to me. As they say, the proof of the pudding is in
> >the eating.
>
> If you have reviewed and tested the patch then please update the
> STATUS file. I won't commit until there are at least three +1s.
>
> I have tried to make reviewing as simple as possible. See
> http://apache.org/~fanf/http_protocol.c
> http://apache.org/~fanf/http_protocol.c.current.patch
> http://apache.org/~fanf/http_protocol.c.1.3.14.patch
>
> Tony.
> --
> f.a.n.finch fanf@covalent.net dot@dotat.at
> "There are flying saucers. There's no doubt they are
> in our skies. They've been there for some time."
--
Paul Marquis
pmarquis@pobox.com
Re: 1.3.15 byte ranges
Posted by Tony Finch <do...@dotat.at>.
Bill Stoddard <bi...@wstoddard.com> wrote:
>
>It looks okay to me. As they say, the proof of the pudding is in the
>eating.
If you have reviewed and tested the patch then please update the
STATUS file. I won't commit until there are at least three +1s.
I have tried to make reviewing as simple as possible. See
http://apache.org/~fanf/http_protocol.c
http://apache.org/~fanf/http_protocol.c.current.patch
http://apache.org/~fanf/http_protocol.c.1.3.14.patch
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"There are flying saucers. There's no doubt they are
in our skies. They've been there for some time."
Re: 1.3.15 byte ranges
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Tue, Jan 16, 2001 at 10:50:47AM -0500, Bill Stoddard wrote:
>
> It looks okay to me. As they say, the proof of the pudding is in the eating. I
> am +1 for including it in 1.3.15; let's roll the tarball and do a release. If
> it breaks, lets fix it and move on to 1.3.16.
My testing (in comparison to the prior apache versions) is +1: it does what
it should do (but didn't do that in the past). So: bug fixed, let's roll!
I agree that a short "settling time" should be there before actually
releasing.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: 1.3.15 byte ranges
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Jim Jagielski <ji...@jaguNET.com> wrote:
> >I'd like to propose that the patch be commited and the review process
> >and test be done on the 1.3.15 tree with it in place. Basically,
> >C-T-R
> >
> >I think we'll get a better peer review.
>
> I'm against this because I want to be sure that it gets reviewed
> before release, and not by our poor users finding bugs on live servers
> like in 1.3.14.
>
It looks okay to me. As they say, the proof of the pudding is in the eating. I
am +1 for including it in 1.3.15; let's roll the tarball and do a release. If
it breaks, lets fix it and move on to 1.3.16.
Bill
Re: 1.3.15 byte ranges
Posted by Tony Finch <do...@dotat.at>.
Jim Jagielski <ji...@jaguNET.com> wrote:
>I'd like to propose that the patch be commited and the review process
>and test be done on the 1.3.15 tree with it in place. Basically,
>C-T-R
>
>I think we'll get a better peer review.
I'm against this because I want to be sure that it gets reviewed
before release, and not by our poor users finding bugs on live servers
like in 1.3.14.
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"There are flying saucers. There's no doubt they are
in our skies. They've been there for some time."