www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From br...@hyperreal.org
Subject Re: protocol/2107: Additional arguments for fixing PR#1464 ("Range: 0-" bug)
Date Wed, 06 May 1998 04:44:02 GMT
[In order for any reply to be added to the PR database, ]
[you need to include <apbugs@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]

Synopsis: Additional arguments for fixing PR#1464 ("Range: 0-" bug)

State-Changed-From-To: open-closed
State-Changed-By: brian
State-Changed-When: Tue May  5 21:44:01 PDT 1998

Apache's current behavior is correct.  In response to your points:

> 1) All HTTP/1.1 compatible servers excepting Apache do it.

Not extremely relevant.

> 2) All transfer tools which are able to do reget (like GetRight, ReGet and many others)
> expect 206 as result for "Range: 0-", not 200.

They should be fixed to look for a "Accept-Ranges" in a response, not a
header.  Overloading "206" to mean "this server accepts range requests"
is an abuse of the protocol.

> 3) RFC 2068 eslecially points that the server MUST return 206 for ANY Range: request.

Where?  That's not even possible - the resource might not even exist, so how
can it return a 206 instead of a 404?  I'm not being facetious here.

> In the reply to PR#1464 I see the point that remote soft can determine reget ability
> using "Accept-ranges" header, but it require yet one additional and totally unneded transfer
> just for "Accept-ranges",  while with 206 return code remote soft can determine reget
ability in ONE 
> initial request using "Range: 0-".

No, "Accept-Ranges" is in every response which can be byte-ranged, so each method
only takes one request to determine if a resource can be fetched using byte 

View raw message