Re: Question on byte ranges

On Tue, 4 Nov 1997, Dave Kristol wrote:

> Jeffrey Mogul wrote:
> > [...]
> > (3) Also in section 14.36.1 Byte Ranges, before the paragraph that
> > starts "Examples of byte-ranges-specifier values ...", insert this
> > paragraph:
> > 
> >         If a syntactically valid byte-range-set includes at least one
> >         byte-range-spec whose first-byte-pos is less than the current
> >         length of the entity-body, or at least one
> >         suffix-byte-range-spec with a non-zero suffix-length, then the
> >         byte-range-set is satisfiable.  Otherwise, the byte-range-set
> >         is unsatisfiable.  If the byte-range-set is unsatisfiable, the
> >         server SHOULD return a response with a status of 416 (Requested
> >         range not satisfiable).  Otherwise, the server SHOULD return a
> >         response with a status of 206 (Partial Content) containing the
> >         satisfiable ranges of the entity-body.
> 
> That's much clearer.  But I think it's backward.  I think 416 should
> mean the request (and therefore the client) is buggy.  And if none of
> the ranges are satisfiable, return everything (pretend there's no Range
> header).  I think it's a little strange to return an error if the Range
> header was well-formed and ignore Range if it's ill-formed.
> 
> Dave Kristol
> 

I also think this clears up the meaning.  Thanks.

But I would like to see 416 returned if the request is either
syntactically incorrect or unsatisfiable.  I agree with Dave that it
is strange to ignore a syntactically incorrect header.  It is unlikely
to be helpful to the (buggy) client.  Indeed, to the user it might
well look like the server is buggy.  I much prefer for the server to
announce definitively, "Hey, your client screwed up!"

But it also makes sense to communicate the correct length of the 
resource when the client has somehow misjudged it.  So an error 
message for an unsatisfiable request is a good idea.

John Franks
john@math.nwu.edu

Received on Tuesday, 4 November 1997 15:07:28 UTC