Re: 3.17.2 Byte Ranges

Jeff writes:
> I'm not sure about that last implication.  I think we really have
> two choices:
> 	(1) the server returns a straightforward interpretation
> 	of what the client asked for, and if the client doesn't
> 	like it, the client can ask for something different.
> 	(2) the server tries to protect the client from receiving
> 	something that might or might not be what the client
> 	wants.
> 
> Choice #2 seems to be unnecessarily restrictive.  Since the responses
> are always unambiguously marked with a Content-Range header, there
> is no danger (if we adopt choice #1) of confusing a properly implemented
> client.  However, #2 runs the risk of requiring an extra round-trip
> in a case where the client might actually be happy with the 1500-1799
> range.

<deletia, detailing various scenarios>


> I believe the intention behind this rule is to say that if a server
> receives something obviously bogus like
> 
> 	GET /foo.gif HTTP/1.1
> 	Range: 4-3
> 
> then it should return the whole entity rather than an error.   But
> maybe the server should return 400 (Bad Request) in this case.
> 
> -Jeff
> 

Sigh.  And it all looked so simple, briefly.  I think that returning
the whole entity is a reasonable response whenever the byte-range-spec
doesn't fit reality.  There may be cases where a client wants the last
300 bytes of something that it thought had 700 more bytes, but I'm not
very comfortable with them.  If the client doesn't care about how many
bytes remain, there are already other, better ways of handling that,
and they fit situations where the client is uncertain about how many
bytes remain (or just wants "from here to the end"). It is also easy
for the client to know what to do with the whole entity, and sending
the whole entity means that the client doesn't need to do any new
checks for integrity.  I believe Jeff is right that this problem won't
occur very often for well-implemented clients, but I think that the
problem *will* occur.

I propose the following wording change within 3.17.2 :

Delete:

      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.
  and
      If the last-byte-pos value is larger than the current length of the
      entity, it is assumed to be equal to the current length of the entity.	 

Insert after "If the last-byte-pos value is absent":

      If the last-byte-pos value is present, it must represent a possible
      value within the byte-range-spec.  It must be greater than or equal
      to the first-byte-pos in the byte-range-spec and less than or equal
      to the current length of the entity in bytes.  Similarly, if the first-
      byte-pos is present, it must represent a possible value.  It must be 
      greater than or equal to zero and it must not be greater than the 
      last-byte-pos value.  The recipient of an invalid byte-range-spec
      must ignore it and return the entire entity.


This is more restrictive than the original wording, but I believe it
closes off an ambiguity and makes for a set of rules which will be
easy for implementors to follow.

				
Comments?

				regards,
					Ted Hardie

Received on Thursday, 25 April 1996 17:01:49 UTC