The following reply was made to PR protocol/2107; it has been noted by GNATS.
From: Marc Slemko <[EMAIL PROTECTED]>
To: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <[EMAIL PROTECTED]>
Cc: Apache bugs database <[EMAIL PROTECTED]>
Subject: Re: protocol/2107: Additional arguments for fixing PR#1464 ("Range:
0-" bug)
Date: Wed, 6 May 1998 09:49:52 -0600 (MDT)
On Wed, 6 May 1998, [koi8-r] =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7 wrote:
> On Wed, May 06, 1998 at 04:44:02AM -0000, [EMAIL PROTECTED] wrote:
> > > 3) RFC 2068 eslecially points that the server MUST return 206 for ANY=
Range: request.
> >=20
> > Where? That's not even possible - the resource might not even exist, s=
o how
> > can it return a 206 instead of a 404? I'm not being facetious here.
>=20
> Well, not ANY but ANY SUCCESSFUL, exact quote is:
>=20
> ---
> If the server supports the Range header and the specified range or
> ranges are appropriate for the entity:
>=20
> o The presence of a Range header in an unconditional GET modifies
> what is returned if the GET is otherwise successful. In other
> words, the response carries a status code of 206 (Partial
> Content) instead of 200 (OK).
> ---
>=20
> As I read it - "the presence of a Range header" cause "the response
> carries 206 instead of 200"
Note that this says "if the server supports the Range header and the
specified range or ranges are appropriate". =20
However, right above what you quote it says:
A server MAY ignore the Range header. However, HTTP/1.1 origin
servers and intermediate caches SHOULD support byte ranges when
possible, since Range supports efficient recovery from partially
failed transfers, and supports efficient partial retrieval of large
entities.
So, in this case, the specified range is decided to be inappropriate for
the resource because it covers the whole thing, so the entire thing is
sent. In that case, no 206 is required because it isn't partial content.
There is no qualification for when it may ignore the Range header.
