Re: byte range questions

John Franks <john@math.nwu.edu> wrote on Fri, 31 Oct 1997 19:09:10 -0600 (CST):

  > Here is a question arising from the interoperability test.
  > 
  > If a server receives a byte range requests for a 100 byte file like
  > 
  > a)   Range: bytes = 0-10, 130-140
  > or
  > b)   Range: bytes = 30-20
  > or
  > c)   Range: bytes = 0-10, 30-20, 40-50
  > 
  > 
  > what is the correct response?  
  > 
  > In case a) one of the two ranges is invalid, but the spec says send
  > a 416 only if *all* are invalid.  If the valid ones are returned with
  > a 206 then there is no way to signal an error.  
  > 
  > In case b) the spec says
  > 
  >             If the last-byte-pos value is present, it must be greater
  >             than or equal to the first-byte-pos in that byte-range-spec,
  >             or the byte-range-spec is invalid. The recipient of an
  >             invalid byte-range-spec must ignore it.
  > 
  > If the server ignores it then it should send what?
  > 
  > Case c) is like b) except it is possible to send the valid ranges.
  > [...]

My reading is that 416 is meant for use when the server parses Range
and finds no valid byte-range-spec or suffix-byte-range-spec.  For case
(a), the client should recognize that it didn't get all the ranges it
asked for.  (That's the error indication.)  Similarly in case (c).  So
only case (b) would get a 416 error response.

However, I have a problem with section 10.4.17, 416 Requested range not
found.  The helpful hint, "(For byte-ranges, this means that the
first-byte-pos of all of the byte-range-spec values were greater than
the current length of the selected resource.)" is incorrect.  The
byte-range-spec "30-20" (as in (b) above) is invalid, but the
first-byte-pos is valid.

I also have to join in John Franks's follow-up question about
Content-Range and a 417 response.  Section 14.17 says "The
Content-Range entity-header is sent with a partial entity-body ...."
But when a server sends a 417 response, there is *no* entity.
So it appears that sections 10.4.17 and 14.17 are inconsistent.

Dave Kristol

Received on Monday, 3 November 1997 09:12:59 UTC