W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: Whatever happened with Partial PUTs

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 4 Feb 2002 13:43:05 -0800
To: "Jim Luther" <luther.j@apple.com>, <w3c-dist-auth@w3c.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKEEFFDFAA.lisa@xythos.com>
Here's a rough proposal on your topic:

http://www.sharemation.com/~milele/public/rsync-specification.htm

RSync is a rather powerful tool for the purpose because the client doesn't
have to maintain a past history of copies of the file in order to provide
the server with diffs (the reverse is also true).

There was also some interest on this kind of thing on the dav-dev list
recently.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther
> Sent: Monday, February 04, 2002 11:05 AM
> To: w3c-dist-auth@w3c.org
> Subject: Whatever happened with Partial PUTs
>
>
> Hi,
>
> Last week I posted something to the HTTP list (copied below) and I've
> received no response. So this morning I searched the w3c archives and
> found that my issue had been discussed before on this list (see
> <http://lists.w3.org/Archives/Public/w3c-dist-
> auth/1997JanMar/thread.html> and look for "Partial Put"). However, I
> didn't find that the issue of partial or ranged PUTs has ever been
> resolved.
>
> As Yaron Goland said at the time
> <http://lists.w3.org/Archives/Public/w3c-dist-
> auth/1997JanMar/0258.html>, "As anyone running on a 28.8 modem or less
> will tell you, this isn't an optimization, this features determines if
> the user can function." I wouldn't limit that to 28.8 modems -- with
> large enough files, this can even affect users with fast connections.
>
> I know that mod_dav allows Content-Range headers with PUTs. However, it
> only allows a file's existing content to be changed and for new content
> to be appended to the end of the existing content. We also need to be
> able to change the length of a resource without changing the content.
>
> So, what happened with this issue?
>
> Jim Luther
> Apple Computer, Inc.
>
> > From: Jim Luther <luther.j@apple.com>
> > Date: Thu Jan 31, 2002  06:13:20 PM US/Pacific
> > To: http-wg@cuckoo.hpl.hp.com
> > Subject: Ranged PUT and changing an entity's length
> >
> > Hi,
> >
> > Mac OS X has a file system which uses HTTP and the WebDAV extensions.
> > Today, when an file entity on a DAV server is opened with write access,
> > our file system GETs the entire entity from the server and then works
> > with the local copy. When that entity is closed or synced, the local
> > copy is PUT back to the server.
> >
> > I'd like to change our code so that individual write requests to the
> > server entity are write-through to the server, but to do that, I need
> > to be able to do a ranged PUT with the range possibly starting and
> > ending beyond the entity's current instance-length (the current length
> > of the entity on the server). In addition, to be able to handle seek
> > and truncate requests, I need to be able to change the instance-length
> > without changing any data to both to make the entity either larger or
> > smaller.
> >
> > RFC 2616 doesn't really say how a Content-Range header might be used to
> > specify a ranged PUT request (it only discusses how a server would use
> > it to reply to a ranged GET), and nowhere that I can find does the RFC
> > say how the length of an entity can be changed (although I was thinking
> > that maybe the byte-content-range-spec in a Content-Range header could
> > look something like "bytes */100" to set the length of an entity to 100
> > without changing any data).
> >
> > So, my two questions:
> >
> > 1 - Are ranged PUTs possible and if so, what should the headers look
> > like?
> >
> > 2 - Can the length of an entity be changed and if so, what should the
> > headers look like?
> >
> > Thanks,
> >
> > Jim Luther
> > Apple Computer
>
Received on Monday, 4 February 2002 16:45:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT