- From: Dave Long <dave@navisoft.com>
- Date: Fri, 29 Dec 1995 20:15:22 -0800
- 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.
>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
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 UTC