Re: holding connections open: a modest proposal
Rick Troth (troth@is.rice.edu)
Wed, 14 Sep 1994 10:27:24 -0500
I've been putting off getting into this thread because it has
fundamental implications and requirements that go beyond HTTP.
On Sep 12, 9:14pm, Dave Kristol wrote:
>
> What's New:
> 1) A server keeps the connection to the client live after a transaction
> (e.g., GET).
> 2) A client sends a QUIT command (like FTP clients) when it wants to
> close a connection. Otherwise it keeps its connection to the server
> open at the end of a transaction.
It's trivial to add a QUIT command to a server.
It's non-trivial to indicate end-of-file without closing the
TCP connection. This is probably why FTP uses a second TCP connection
(but I'm not Postel; you'll have to ask him)
MIME is a Good Thing. Multipart/mixed is a Good Thing.
Given the lack of out-of-band EOF indicators aside from shutting down,
multipart/mixed with just >one< object may help a bit. The problem
then becomes keeping the multipart boundary unique or (better) out of band.
This implies Base64 encoding for too many things.
> When a QUIT-capable client talks to a non-QUIT capable server, it will
> experience an unexpected close of the connection -- what the server does
> now. It will simply know to create a new connection if it needs further
> information from that server.
Yes. This will work.
> When a non-QUIT-capable client talks to a QUIT-capable server, the
> server will experience an unexpected close while it awaits a command.
> The server treats that like an implicit QUIT. The server times out if
> it fails to get a new command "soon enough".
No. It will always time out. The clients will see "slow"
response times. The client doesn't close the socket until it sees the
close on the server's end. It's too bad that TCP is always implemented
with just one file descriptor. Wouldn't it be useful (in cases like this)
if the client could close its sending fd w/o closing its receiving fd?
> David M. Kristol
> AT&T Bell Laboratories
So ... I like the idea of a QUIT command. Added QUIT to a certain
HTTP server I wrote. (but I'm on Rice time just now so I can't talk
about that ;-) ) But we need "structure" information, starting with an
EOF marker for lingering connections to work, or we need multiple
connections per session ala FTP (please NO).