W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1995

Re: Comments on Byte range draft

From: Laurent Demailly <dl@hplyot.obspm.fr>
Date: Tue, 14 Nov 1995 10:41:08 +0100
Message-Id: <9511140941.AA03199@hplyot.obspm.fr>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: Larry Masinter <masinter@parc.xerox.com>, Ari Luotonen <luotonen@netscape.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I agree that there should be some *opaque* string used to select if the
object is the same or not (string which could be for instance a last
modified date, an MD5 digest,... whatever the server wants)
And the client could for instance blindy use what the server sent as
Content-Digest: (for instance, but we could use a different name if that
one is 'burned' ;-) )

GET /someurl HTTP/1.x
server answers:
HTTP/1.0 200 Document follows
Content-Digest: DATE="Nov 14 10:26:03 1995"; MD5=0906bdfddce0964b42ad656 
Content-Lenght: 12000

Later client requests
GET /someurl HTTP/1.x
Request-Range: 6000-12000
Partial-If-Digest: DATE="Nov 14 10:26:03 1995"; MD5=0906bdfddce0964b42ad656
( that name is also open to any better suggestion )

2 main cases now,
1) server does not understand /deals with Request-Range:
HTTP/1.0 200 Document follows
full object again
2) server do understand, 2 sub cases:
   a) digest,... is the same, ok
      HTTP/1.0 206 Partial Content
      Range: 6000-12000
   b) digest,... is NOT the same, there we have two options again
        i) send the whole thing again (to save 
           a request in the most probable case that the client would
           request it anyway)
        ii) send some error like some HTTP/1.0 3XX Changed  (or 4XX ?)
           thus saving a bit of bandwith in the case the client
           would throw it away

My preference goes to "i)" but maybe both way be valid ?

Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|...  Freedom
Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept
Received on Tuesday, 14 November 1995 01:48:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC