RANGE-ERROR issue: proposed resolution

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