- From: Shel Kaphan <sjk@amazon.com>
- Date: Mon, 13 Nov 1995 14:55:16 -0800
- To: Lou Montulli <montulli@mozilla.com>
- Cc: Gavin Nicol <gtn@ebt.com>, fielding@avron.ICS.UCI.EDU, masinter@parc.xerox.com, ari@netscape.com, john@math.nwu.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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
Received on Monday, 13 November 1995 15:04:32 UTC