You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/11/23 22:41:52 UTC
protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-" (fwd)
Comments?
This behaviour is caused by:
return (*start > 0 || *end < clength - 1);
and, in the general case, it makes sense to behave this way. If you send
a 206, then a good number of caches will not be able to cache the
response, which sucks.
So what is the accepted way to figure out if a server can send byte-ranges
for a particular request? Do a HEAD? That isn't very nice.
---------- Forwarded message ----------
Received: from apache.org (uucp@localhost) by alive.znep.com (8.7.5/8.7.3) with UUCP id OAA24493 for marcs@znep.com; Sun, 23 Nov 1997 14:30:02 -0700 (MST)
Received: from hyperreal.org (taz.hyperreal.org [204.62.130.147])
by scanner.worldgate.com (8.8.7/8.8.7) with SMTP id OAA20867
for <ma...@znep.com>; Sun, 23 Nov 1997 14:30:11 -0700 (MST)
Received: (qmail 6431 invoked by uid 6000); 23 Nov 1997 21:30:06 -0000
Received: (qmail 6385 invoked by uid 2001); 23 Nov 1997 21:30:01 -0000
Received: (qmail 4892 invoked by uid 2012); 23 Nov 1997 21:22:58 -0000
Message-Id: <19...@hyperreal.org>
Date: 23 Nov 1997 21:22:58 -0000
From: Michael Burford <mj...@headlightsw.com>
Reply-To: mjb@headlightsw.com
To: apbugs@hyperreal.org
X-Send-Pr-Version: 3.2
Subject: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-"
Sender: apache-bugdb-owner@apache.org
Precedence: bulk
>Number: 1464
>Category: protocol
>Synopsis: Response for Byte-Range containing whole file "Range: bytes=0-"
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: apache
>State: open
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Sun Nov 23 13:30:01 PST 1997
>Last-Modified:
>Originator: mjb@headlightsw.com
>Organization:
apache
>Release: Server: Apache/1.3b3
>Environment:
Not my server so I don't know.
>Description:
While I don't think it is a bug, some of my users have commented on this and
it could cause confusion.
When doing a byte-range request, GetRight (and probably other tools) will
do the first request from "Range: bytes=0-". It uses the response (206 or 200) to
indicate if the server will allow it to resume later if this transfer
is disconnected.
(GetRight may be downloaded from http://www.getright.com/ )
It appears that 1.3b3 returns a 200 response if the range is for the while file
("0-"), but 206 otherwise.
While it doesn't really cause any problems, GetRight will interpret the 200 response
as meaning the server will not allow resuming. Some users may try to find some
other server to download since it doesn't appear that this server will let
them resume later.
-------------Headers for byterange "0-"-------
----Header Sent----
GET /sounds/WAV/Rafiki.zip HTTP/1.1
Host: www.lionking.org
Range: bytes=0-
User-Agent: GetRight/3.02
Accept: *.*, */*
Range-If: Fri, 25 Apr 1997 20:28:04 GMT
----Header Recv----
HTTP/1.1 200 OK
Date: Sun, 23 Nov 1997 21:09:27 GMT
Server: Apache/1.3b3 mod_perl/1.06
Last-Modified: Fri, 25 Apr 1997 20:28:04 GMT
ETag: "4b46f-1a80fb-336113d4"
Content-Length: 1736955
Content-Type: application/zip
-------------Headers for regular byterange-------
----Header Sent----
GET /sounds/WAV/Rafiki.zip HTTP/1.1
Host: www.lionking.org
Range: bytes=60527-
User-Agent: GetRight/3.02
Accept: *.*, */*
Range-If: Fri, 25 Apr 1997 20:28:04 GMT
----Header Recv----
HTTP/1.1 206 Partial Content
Date: Sun, 23 Nov 1997 21:20:17 GMT
Server: Apache/1.3b3 mod_perl/1.06
Last-Modified: Fri, 25 Apr 1997 20:28:04 GMT
ETag: "4b46f-1a80fb-336113d4"
Content-Length: 1676428
Content-Range: bytes 60527-1736954/1736955
Content-Type: application/zip
>How-To-Repeat:
http://www.lionking.org/sounds/WAV/Rafiki.zip
>Fix:
Either Apache can always return a 206 for any byte-range request, or GetRight
can parse the Server response & know that Apache/1.2 or higher really will
resume--but it may not actually be able to resume if there is some Proxy
server in the middle that doesn't know about HTTP 1.1
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
Re: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-" (fwd)
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Sun, 23 Nov 1997, Marc Slemko wrote:
> > Check for an Accept-Ranges header. Although it's not required, most
> > servers will send them for entities that support ranges.
>
> Aha. Apache doesn't for bytes=0- (well, any byte range, but others have a
> 206).
Right. It's not supposed to. It only sends them for a 200. I very much
consider Apache's behavior as pointed out by the bug report to be a bug,
if only for this reason "bytes=0-" is a perfectly valid range; Apache
sends "Accept-Ranges: bytes" with a given entity, but does not serve
"bytes=0-" as a range.
> > Though I must admit that sending a "Range: bytes=0-" and checking the
> > response code is a pretty clever idea.
>
> I'm still not thrilled with the caching implications. I would bet that on
> most caches this makes the response uncachable. It also adds a touch of
> overhead to the request that isn't necessary. I like keeping things the
> simplest possible.
So? If the client wants to screw caching, that's their problem. We can't
tell them what to do. And byteranges have certain caching implications
anyway. We can't do anything about that.
+1 on fixing the problem (it's a one-character patch, I posted it
earlier)
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-" (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 23 Nov 1997, Alexei Kosut wrote:
> On Sun, 23 Nov 1997, Marc Slemko wrote:
>
> [Requests for "Range: bytes=0-" return a 200 request]
>
> > Comments?
> >
> > This behaviour is caused by:
> >
> > return (*start > 0 || *end < clength - 1);
> >
> > and, in the general case, it makes sense to behave this way. If you send
> > a 206, then a good number of caches will not be able to cache the
> > response, which sucks.
>
> Except that "bytes=0-" is a range. And we probably should send it. The
> code wasn't written that way with this case in mind; it was written to
> catch out-of-band ranges, and just send them 200s (that's what the spec
> says, if I recall). The "*end < clength - 1" should probably be an
> "*end <= clength - 1".
>
> That would fix this problem.
>
> > So what is the accepted way to figure out if a server can send byte-ranges
> > for a particular request? Do a HEAD? That isn't very nice.
>
> Check for an Accept-Ranges header. Although it's not required, most
> servers will send them for entities that support ranges.
Aha. Apache doesn't for bytes=0- (well, any byte range, but others have a
206).
I think I like Apache sending what it does now for this sort of request,
except with an Accept-Ranges header and tell the client author to check
for Accept-Ranges as well.
> Though I must admit that sending a "Range: bytes=0-" and checking the
> response code is a pretty clever idea.
I'm still not thrilled with the caching implications. I would bet that on
most caches this makes the response uncachable. It also adds a touch of
overhead to the request that isn't necessary. I like keeping things the
simplest possible.
Re: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-" (fwd)
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Sun, 23 Nov 1997, Marc Slemko wrote:
[Requests for "Range: bytes=0-" return a 200 request]
> Comments?
>
> This behaviour is caused by:
>
> return (*start > 0 || *end < clength - 1);
>
> and, in the general case, it makes sense to behave this way. If you send
> a 206, then a good number of caches will not be able to cache the
> response, which sucks.
Except that "bytes=0-" is a range. And we probably should send it. The
code wasn't written that way with this case in mind; it was written to
catch out-of-band ranges, and just send them 200s (that's what the spec
says, if I recall). The "*end < clength - 1" should probably be an
"*end <= clength - 1".
That would fix this problem.
> So what is the accepted way to figure out if a server can send byte-ranges
> for a particular request? Do a HEAD? That isn't very nice.
Check for an Accept-Ranges header. Although it's not required, most
servers will send them for entities that support ranges.
Though I must admit that sending a "Range: bytes=0-" and checking the
response code is a pretty clever idea.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-" (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
On Mon, 15 Dec 1997, Dean Gaudet wrote:
> Marc, Alexei, and Roy went back and forth on this for a bit... I think
> we've still got an outstanding bug here. But I lost track of what it was
> or what the fix was. Can one of you repost?
Either, there is a bug in that we don't send range headers when
the request represents the entire document (Alexei thinks this) or
not sending range headers when the request is for the entire document
is fine (I think that, and I think Roy does; it isn't incorrect,
and needlessly doing byte ranges should be discouraged because it
can hurt caching) but then we have a bug of not sending an Accept:
header for such requests.
>
> Dean
>
> On Sun, 23 Nov 1997, Marc Slemko wrote:
>
> > Comments?
> >
> > This behaviour is caused by:
> >
> > return (*start > 0 || *end < clength - 1);
> >
> > and, in the general case, it makes sense to behave this way. If you send
> > a 206, then a good number of caches will not be able to cache the
> > response, which sucks.
> >
> > So what is the accepted way to figure out if a server can send byte-ranges
> > for a particular request? Do a HEAD? That isn't very nice.
> >
> > ---------- Forwarded message ----------
> > Received: from apache.org (uucp@localhost) by alive.znep.com (8.7.5/8.7.3) with UUCP id OAA24493 for marcs@znep.com; Sun, 23 Nov 1997 14:30:02 -0700 (MST)
> > Received: from hyperreal.org (taz.hyperreal.org [204.62.130.147])
> > by scanner.worldgate.com (8.8.7/8.8.7) with SMTP id OAA20867
> > for <ma...@znep.com>; Sun, 23 Nov 1997 14:30:11 -0700 (MST)
> > Received: (qmail 6431 invoked by uid 6000); 23 Nov 1997 21:30:06 -0000
> > Received: (qmail 6385 invoked by uid 2001); 23 Nov 1997 21:30:01 -0000
> > Received: (qmail 4892 invoked by uid 2012); 23 Nov 1997 21:22:58 -0000
> > Message-Id: <19...@hyperreal.org>
> > Date: 23 Nov 1997 21:22:58 -0000
> > From: Michael Burford <mj...@headlightsw.com>
> > Reply-To: mjb@headlightsw.com
> > To: apbugs@hyperreal.org
> > X-Send-Pr-Version: 3.2
> > Subject: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-"
> > Sender: apache-bugdb-owner@apache.org
> > Precedence: bulk
> >
> >
> > >Number: 1464
> > >Category: protocol
> > >Synopsis: Response for Byte-Range containing whole file "Range: bytes=0-"
> > >Confidential: no
> > >Severity: non-critical
> > >Priority: medium
> > >Responsible: apache
> > >State: open
> > >Class: sw-bug
> > >Submitter-Id: apache
> > >Arrival-Date: Sun Nov 23 13:30:01 PST 1997
> > >Last-Modified:
> > >Originator: mjb@headlightsw.com
> > >Organization:
> > apache
> > >Release: Server: Apache/1.3b3
> > >Environment:
> > Not my server so I don't know.
> > >Description:
> > While I don't think it is a bug, some of my users have commented on this and
> > it could cause confusion.
> >
> > When doing a byte-range request, GetRight (and probably other tools) will
> > do the first request from "Range: bytes=0-". It uses the response (206 or 200) to
> > indicate if the server will allow it to resume later if this transfer
> > is disconnected.
> > (GetRight may be downloaded from http://www.getright.com/ )
> >
> > It appears that 1.3b3 returns a 200 response if the range is for the while file
> > ("0-"), but 206 otherwise.
> >
> > While it doesn't really cause any problems, GetRight will interpret the 200 response
> > as meaning the server will not allow resuming. Some users may try to find some
> > other server to download since it doesn't appear that this server will let
> > them resume later.
> >
> > -------------Headers for byterange "0-"-------
> > ----Header Sent----
> > GET /sounds/WAV/Rafiki.zip HTTP/1.1
> > Host: www.lionking.org
> > Range: bytes=0-
> > User-Agent: GetRight/3.02
> > Accept: *.*, */*
> > Range-If: Fri, 25 Apr 1997 20:28:04 GMT
> >
> > ----Header Recv----
> > HTTP/1.1 200 OK
> > Date: Sun, 23 Nov 1997 21:09:27 GMT
> > Server: Apache/1.3b3 mod_perl/1.06
> > Last-Modified: Fri, 25 Apr 1997 20:28:04 GMT
> > ETag: "4b46f-1a80fb-336113d4"
> > Content-Length: 1736955
> > Content-Type: application/zip
> >
> > -------------Headers for regular byterange-------
> > ----Header Sent----
> > GET /sounds/WAV/Rafiki.zip HTTP/1.1
> > Host: www.lionking.org
> > Range: bytes=60527-
> > User-Agent: GetRight/3.02
> > Accept: *.*, */*
> > Range-If: Fri, 25 Apr 1997 20:28:04 GMT
> >
> > ----Header Recv----
> > HTTP/1.1 206 Partial Content
> > Date: Sun, 23 Nov 1997 21:20:17 GMT
> > Server: Apache/1.3b3 mod_perl/1.06
> > Last-Modified: Fri, 25 Apr 1997 20:28:04 GMT
> > ETag: "4b46f-1a80fb-336113d4"
> > Content-Length: 1676428
> > Content-Range: bytes 60527-1736954/1736955
> > Content-Type: application/zip
> >
> > >How-To-Repeat:
> > http://www.lionking.org/sounds/WAV/Rafiki.zip
> > >Fix:
> > Either Apache can always return a 206 for any byte-range request, or GetRight
> > can parse the Server response & know that Apache/1.2 or higher really will
> > resume--but it may not actually be able to resume if there is some Proxy
> > server in the middle that doesn't know about HTTP 1.1
> > >Audit-Trail:
> > >Unformatted:
> > [In order for any reply to be added to the PR database, ]
> > [you need to include <ap...@Apache.Org> in the Cc line ]
> > [and leave the subject line UNCHANGED. This is not done]
> > [automatically because of the potential for mail loops. ]
> >
> >
> >
> >
>
Re: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-" (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Marc, Alexei, and Roy went back and forth on this for a bit... I think
we've still got an outstanding bug here. But I lost track of what it was
or what the fix was. Can one of you repost?
Dean
On Sun, 23 Nov 1997, Marc Slemko wrote:
> Comments?
>
> This behaviour is caused by:
>
> return (*start > 0 || *end < clength - 1);
>
> and, in the general case, it makes sense to behave this way. If you send
> a 206, then a good number of caches will not be able to cache the
> response, which sucks.
>
> So what is the accepted way to figure out if a server can send byte-ranges
> for a particular request? Do a HEAD? That isn't very nice.
>
> ---------- Forwarded message ----------
> Received: from apache.org (uucp@localhost) by alive.znep.com (8.7.5/8.7.3) with UUCP id OAA24493 for marcs@znep.com; Sun, 23 Nov 1997 14:30:02 -0700 (MST)
> Received: from hyperreal.org (taz.hyperreal.org [204.62.130.147])
> by scanner.worldgate.com (8.8.7/8.8.7) with SMTP id OAA20867
> for <ma...@znep.com>; Sun, 23 Nov 1997 14:30:11 -0700 (MST)
> Received: (qmail 6431 invoked by uid 6000); 23 Nov 1997 21:30:06 -0000
> Received: (qmail 6385 invoked by uid 2001); 23 Nov 1997 21:30:01 -0000
> Received: (qmail 4892 invoked by uid 2012); 23 Nov 1997 21:22:58 -0000
> Message-Id: <19...@hyperreal.org>
> Date: 23 Nov 1997 21:22:58 -0000
> From: Michael Burford <mj...@headlightsw.com>
> Reply-To: mjb@headlightsw.com
> To: apbugs@hyperreal.org
> X-Send-Pr-Version: 3.2
> Subject: protocol/1464: Response for Byte-Range containing whole file "Range: bytes=0-"
> Sender: apache-bugdb-owner@apache.org
> Precedence: bulk
>
>
> >Number: 1464
> >Category: protocol
> >Synopsis: Response for Byte-Range containing whole file "Range: bytes=0-"
> >Confidential: no
> >Severity: non-critical
> >Priority: medium
> >Responsible: apache
> >State: open
> >Class: sw-bug
> >Submitter-Id: apache
> >Arrival-Date: Sun Nov 23 13:30:01 PST 1997
> >Last-Modified:
> >Originator: mjb@headlightsw.com
> >Organization:
> apache
> >Release: Server: Apache/1.3b3
> >Environment:
> Not my server so I don't know.
> >Description:
> While I don't think it is a bug, some of my users have commented on this and
> it could cause confusion.
>
> When doing a byte-range request, GetRight (and probably other tools) will
> do the first request from "Range: bytes=0-". It uses the response (206 or 200) to
> indicate if the server will allow it to resume later if this transfer
> is disconnected.
> (GetRight may be downloaded from http://www.getright.com/ )
>
> It appears that 1.3b3 returns a 200 response if the range is for the while file
> ("0-"), but 206 otherwise.
>
> While it doesn't really cause any problems, GetRight will interpret the 200 response
> as meaning the server will not allow resuming. Some users may try to find some
> other server to download since it doesn't appear that this server will let
> them resume later.
>
> -------------Headers for byterange "0-"-------
> ----Header Sent----
> GET /sounds/WAV/Rafiki.zip HTTP/1.1
> Host: www.lionking.org
> Range: bytes=0-
> User-Agent: GetRight/3.02
> Accept: *.*, */*
> Range-If: Fri, 25 Apr 1997 20:28:04 GMT
>
> ----Header Recv----
> HTTP/1.1 200 OK
> Date: Sun, 23 Nov 1997 21:09:27 GMT
> Server: Apache/1.3b3 mod_perl/1.06
> Last-Modified: Fri, 25 Apr 1997 20:28:04 GMT
> ETag: "4b46f-1a80fb-336113d4"
> Content-Length: 1736955
> Content-Type: application/zip
>
> -------------Headers for regular byterange-------
> ----Header Sent----
> GET /sounds/WAV/Rafiki.zip HTTP/1.1
> Host: www.lionking.org
> Range: bytes=60527-
> User-Agent: GetRight/3.02
> Accept: *.*, */*
> Range-If: Fri, 25 Apr 1997 20:28:04 GMT
>
> ----Header Recv----
> HTTP/1.1 206 Partial Content
> Date: Sun, 23 Nov 1997 21:20:17 GMT
> Server: Apache/1.3b3 mod_perl/1.06
> Last-Modified: Fri, 25 Apr 1997 20:28:04 GMT
> ETag: "4b46f-1a80fb-336113d4"
> Content-Length: 1676428
> Content-Range: bytes 60527-1736954/1736955
> Content-Type: application/zip
>
> >How-To-Repeat:
> http://www.lionking.org/sounds/WAV/Rafiki.zip
> >Fix:
> Either Apache can always return a 206 for any byte-range request, or GetRight
> can parse the Server response & know that Apache/1.2 or higher really will
> resume--but it may not actually be able to resume if there is some Proxy
> server in the middle that doesn't know about HTTP 1.1
> >Audit-Trail:
> >Unformatted:
> [In order for any reply to be added to the PR database, ]
> [you need to include <ap...@Apache.Org> in the Cc line ]
> [and leave the subject line UNCHANGED. This is not done]
> [automatically because of the potential for mail loops. ]
>
>
>
>