Re: 3.17.2 Byte Ranges

Jeff writes:     
> I think you are referring to a case like this: /foo.gif is 1024 bytes
> long, and a client sends
> 	GET /foo.gif HTTP/1.1
> 	Range: bytes = 0-2047
> The spec now implies that the returned response would have
> 	Content-Range: bytes 0-1023/1024
> Is this consistent with your reading?
> 

That is consistent with my reading, but it isn't really the case
I was worried about.  Consider the case where a client sends

	GET /foo.gif HTTP/1.1
	Range: bytes = 1500-2047

and foo.gif is only 1800 bytes long.  My reading is that right
now the returned response would have a 

	Content-Range: bytes 1500-1799/1800

And the client would end up with the last 300 bytes, just as if a

	Range bytes = 1500- had been sent.  

It seems that we agree that isn't what we want, and that if the byte
range specified is out of bounds, the robustness prinicipal implies
returning the *whole* entity.  In the case you describe, I can see how
what is written gets the client the whole entity, but I'm not sure
that it does imply that it in all cases.  In other words, I think
there is an ambiguity here that we need to plug.

This makes me wonder whether there isn't another ambiguity here.  I
had assumed from this section:

      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.
 
That the recipient of an invalid byte-range-spec ignored it by treating
the request as if it did not contain a Range: header (once again, returning
the whole entity on a GET request).  Am I misreading that?

			Regards,
				Ted Hardie