- 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
> 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 UTC