Re: safe PUT

Well, after finally getting to play around a bit with working
code*, I'm sticking with my initial counter-proposal of full-duplex
PUT (or full-duplex methods, in general):

a - the client MAY stop sending request data after a response
    is detected

A naive client can use old the HTTP/1.0 request-response, but a more
sophisticated one (well, <<10 lines of code more sophisticated :-)
will stop sending its request after response data is detected in
its read queue.

>From the server's point of view, all this means is that it had
better not send a response until it has all the information it
wants from the request.  Somehow, this doesn't seem like much
of a hardship...

If one wishes to support the 100 continue, then we get up to ~10 lines
of code, and the rule changes to:

b - the client MAY stop sending request data after a _non-100_
    response is detected

off the top of my head:

	+ it's simple, especially (a)
		any argument?

	- data might be sent that wouldn't have been
	  if the client had to wait for a 100.
		We seem to be in mid-argument over
		how important this is...

	- data might not be sent if a server returned its
	  200 response early.
		This is not an introduced problem.  Our
		customers have encountered servers that
		happily read all the PUT request, then
		send a 200 OK, but don't actually do


* I have a windows client that implements something close to (b); let me
  know if you'd like it, or like it on a different platform.

Received on Friday, 29 December 1995 20:20:00 UTC