[In order for any reply to be added to the PR database, ]
[you need to include <[EMAIL PROTECTED]> 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
State-Changed-Why:
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 request
> 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
ranges.
