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

Re: safe PUT

From: Dave Long <dave@navisoft.com>
Date: Fri, 29 Dec 1995 20:15:22 -0800
Message-Id: <199512300415.UAA20583@geek.navisoft.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

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.

rom 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
		anything!

-Dave

* 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 EST

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