- From: Ted Hardie <hardie@merlot.arc.nasa.gov>
- Date: Thu, 25 Apr 1996 15:42:06 -0700 (PDT)
- To: Jeffrey Mogul <mogul@pa.dec.com.o.the.first-byte-pos.in.that.byte-range-spec.or.the.byte-range>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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
Received on Thursday, 25 April 1996 15:51:06 UTC