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

Re: 'PUT' transaction reconsidered (was Re: two-phase send concerns )

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Tue, 26 Dec 1995 22:55:40 -0800
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9512262255.aa23864@paris.ics.uci.edu>
> I'm becoming more and more convenced that single-exchange PUT is
> unworkable. That is, PUT might have to happen in two steps:
> 
> 1. client: wanna PUT this file of this size of this media type 
>   	   in this location with these PERMS with
> 	   this validator 
> 2. server: OK, send file (or permission denied)
> 3. client: OK, here's the file.
> 4. server: OK, got the file

One of the possible solutions we (Henrik and I) discussed this summer was
a two-request form of PUT (using PUTQ as the probe method).  That solution
was discarded because the server's requirements/status may change between
the two requests and thus the second request must still be protected using
the two-phased approach (or something similar).  Therefore, there was no
immediate advantage to using two requests other than for obtaining the
access requirements -- the OPTIONS method does that.

> Step 1 might offer more than one media type with step 2 accepting a
> particular one or a subset. Step 1 might say that it doesn't know the
> file size, for example.

If we allow such negotiation, we must also provide a mechanism for
expressing it.  None is available currently and it's a bit of a rats
nest to come up with one that can encompass the server's options.
On the whole, I think we are better-off having the client ask
"can I do this" for each combination of request until the server
says "go ahead and do that".


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/
Received on Tuesday, 26 December 1995 23:22:01 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:38 EDT