Re: Comments on Byte range draft
Shel Kaphan (sjk@amazon.com)
Mon, 13 Nov 1995 14:55:16 -0800
Lou Montulli writes:
...
An If-modified-since
> request can guarantee that the object hasn't changed. From
> there it's just a simple matter of requesting the parts that
> are missing.
>
That makes this into a two-round-trip protocol to receive just
a part of the object (GET if-modified-since, 304, GET byte-range)
unless you want to change the semantics of GET if-modified-since,
which seems like barking up the wrong tree. (What would it be?
GET if-modified-since unless there's a byte-range in the URL, in which
case, instead of returning the 304, return the byte-range??? Yuck!)
Orthogonality! Orthogonality!!!
If we're actually going to *design* this part of the protocol, let's
design into it that you can pass the last-modified date (at least) to
the server along with the request, in a header, so that you can safely get
the partial resource on one request, and not muck up the meaning of
GET if-modified-since. This also further suggests that the byte-range
should be in a header, or we should use some method other than GET,
rather than putting it into the URL, which conflates two very
different things.
Shel Kaphan