W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Revised "Range:" proposal

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 20 Feb 96 17:08:10 PST
Message-Id: <9602210108.AA10525@acetes.pa.dec.com>
To: http-caching@pa.dec.com
Ari and I have agree on the following, and Ari will be submitting
a revised draft-luotonen-http-url-byterange-XX.txt by the cutoff
date (Thursday).


------- Forwarded Message

Return-Path: mogul
Received: by acetes.pa.dec.com; id AA22205; Fri, 16 Feb 96 15:36:08 -0800
Message-Id: <9602162336.AA22205@acetes.pa.dec.com>
To: luotonen@netscape.com (Ari Luotonen)
Cc: mogul
Subject: range proposal revisions
Date: Fri, 16 Feb 96 15:36:08 PST
From: Jeffrey Mogul <mogul>

Pretty much the only part of draft-luotonen-http-url-byterange-02.txt
that I think needs changing is this section:

3.2. The Unless-Modified-Since HTTP request header

   Guaranteeing that individual parts are all up-to-date and in sync
   with each other is crucial.  This can be made easier by providing a
   way to tell the server to send the byte range only if it hasn't
   changed since the time of the retrieval of the other ranges.  If it
   has, the entire document is transferred instead.

   The Unless-Modified-Since header will be sent by the client to the
   server (or the proxy), carrying the date and time received in the
   Last-Modified header from the previously received parts.  If at any
   point the last-modified date or time mismatch is detected by the
   client, the older parts should be discarded.  The last-modified date
   and time must match exactly.

   The server will send the requested byte range (as a 206 Partial
   Content response, as described below) if and only if the document has
   not changed since that date and time.  If it has, the server will
   send the entire document to the client instead (as a normal 200


        Unless-Modified-Since: Wed, 15 Nov 1995 06:25:15 GMT

   As for Last-Modified-Since header in practice, there may be
   additional parameters in the end of this field, separated by a
   semicolon, to make additional checksums possible.  The most basic one
   is the size of the file as the length parameter:

        Unless-Modified-Since: Wed, 15 Nov 1995 06:25:15 GMT; length=12045

How about this proposal:

	(1) There are three cases of Range retrievals:
		(A) Unconditional ... always returns the
		selected range (if it exists).
		Servers that do not support Range: return entire
		(B) Insertion ... returns the selected
		range if the request-validator is valid,
		otherwise returns entire resource.

		Servers that do not support Range: return entire
		resource if the validator is valid, else return
		nothing + "306 Modified".

	case (B) is for filling in a hole in a cached resource,
	perhaps after an interrupted retrieval, or perhaps after
	a previous Unconditional or Tentative Range: request.

Note that if the server does not support Range:, it requires an
extra round-trip to update a cached resource with a hole in it.

I think your original "Unless-modified-since:" proposal has a
similar inefficiency; there's probably not much that can be
done about that.
		(C) Tentative ... returns the selected
		range if the request-validator is NOT valid,
		otherwise returns nothing + "304 Not Modified"

		Servers that do not support Range: return entire
		resource if the validator is not valid, else return
		nothing + "304 Not Modified".

	case (C) is a way of asking only for a specified range, but in
	a way that reloads it only if the client's cache is stale.  For
	example, you may have a large GIF image in your cache, and you
	may want to know if its GIF header has changed (so that you can
	do an early rendering of the enclosing HTML file), but you do
	not want to retrieve the whole image right away.

My message to the http-wg list in December,
has this last case different (I instead had "returns selected
range if validator is valid, else returns nothing"), but I don't
think that's a useful feature.

	(2) The three cases are implemented in HTTP/1.1 using
	some combination of these three headers
	See (3) below for more about using *-Modified-Since.
	Case A (Unconditional) is done using
		GET /image.gif
		Range: bytes=0-128

	Case B (Insertion) is done using
		GET /image.gif
		Range: bytes=0-128
		If-valid: "xxxyxxyx"
	or perhaps
		GET /image.gif
		Range: bytes=0-128
		Unless-modified-since: Wed, 15 Nov 1995 06:25:15 GMT

	Case C (Tentative) is done using
		GET /image.gif
		Range: bytes=0-128
		If-invalid: "xxxyxxyx"
	or perhaps
		GET /image.gif
		Range: bytes=0-128
		If-modified-since: Wed, 15 Nov 1995 06:25:15 GMT

	(3) We can get rid of "Unless-modified-since:" if we adopt
	the rule that the "If-valid:" header either takes a quoted
	string (in which case it is an opaque validator) or a string
	that does not include quotes (in which case it must be an
	HTTP-date value).  This saves a few header bytes.
	(4) I would remove the stuff about including other "validator"
	information, such as length, from the {Unless,If}-Modified-Since:
	headers.  These are of dubious value, and they make the
	protocol more complex.


------- End of Forwarded Message
Received on Wednesday, 21 February 1996 01:16:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC