- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 05 Jun 97 16:28:30 MDT
- To: http-wg@cuckoo.hpl.hp.com
The HTTP Issues List includes the RANGE-ERROR issue, described as
What should be the correct server response for a byte range that is
outside the actual contents of the file?
See
http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q1/0101.html
for more discussion.
During the last editorial-group meeting, we decided that we need
to introduce a new status code for this case, along with a somewhat
unusual use of the Content-Range header (to indicate to the recipient
what the actual size of the resource is).
I was asked to draft the new specification language; here it is:
(1) In section 6.1.1 (Status Code and Reason Phrase), add to the
BNF for Status-Code (in proper numeric order):
| "416" ; Range Not Valid
(2) Add (new) section:
10.4.17 416 Range Not Valid
The request includes a Range header, and none of the ranges
specified in that header are contained within the current extent of
the requested resource. The response SHOULD include a
Content-Range header (see section 14.17) that specifies an empty
range (i.e., the first-byte-pos is greater than the last-byte-pos)
and the current length of the requested resource. Exception: if
the length cannot be provided, the 416 response SHOULD NOT contain
Content-Range. I.e., in a 416 response, the length given by the
Content-Range header SHOULD NOT be "*", since this provides no
useful information.
The ``explanation of the error situation,'' required by section
10.4, MAY be empty for a 416 response, since this form of invalid
request is most likely generated automatically by a user-agent
attempting to optimize its use of the network.
[This assumes that we will adopt Henrik's suggestion to allow
the use of "Content-Range: bytes 1-1023/*".]
(3) In section 14.17 (Content-Range), change this:
A byte-content-range-spec whose last-byte-pos value is less than its
first-byte-pos value, or whose entity-length value is less than or
equal to its last-byte-pos value, is invalid. The recipient of an
invalid byte-content-range-spec MUST ignore it and any content
transferred along with it.
To this:
A byte-content-range-spec whose last-byte-pos value is less than its
first-byte-pos value, or whose entity-length value is less than or
equal to its last-byte-pos value, is invalid. The recipient of an
invalid byte-content-range-spec MUST ignore it and any content
transferred along with it. Exception: in a 416 (Range Not Valid)
response, the first-byte-pos MUST BE greater than the last-byte-pos.
The Content-Range header in a 416 response does not apply to the
any entity body in that response (which represents an explanation
of the error situation, not the requested resource).
Change this:
If the server ignores a byte-range-spec because it is invalid, the
server should treat the request as if the invalid Range header field
did not exist. (Normally, this means return a 200 response containing
the full entity). The reason is that the only time a client will make
such an invalid request is when the entity is smaller than the entity
retrieved by a prior request.
To this
If the server ignores a byte-range-spec because it is invalid (i.e.,
the first-byte-pos is greater than the last-byte-pos; see section
14.36.1), the server SHOULD treat the request as if the invalid
Range header field did not exist. (Normally, this means return a 200
response containing the full entity).
If the client requests only byte-ranges starting after the last
byte of the requested resource, a server that supports byte-ranges
SHOULD return a 416 (Range Not Valid) response. For example,
HTTP/1.1 416 Range Not Valid
Date: Wed, 15 Nov 1995 06:25:24 GMT
Content-Range: bytes 1-0/470
If any of the ranges specified in the request overlap the
extent of the requested resource, then the server SHOULD NOT
return a 416 response.
-Jeff
Received on Thursday, 5 June 1997 16:38:25 UTC