Richard said:
With a context-devoid, connectionless, pile-of-pooh like HTTP, the options
are clearly limited.
HTTP is sessionless. It's not connectionless (at least not over TCP,
which is the only transport used in practice). And when the client
does its close or half-close, the HTTP server will get a FIN (modulo
network failure), just like any other TCP application.
If on the other hand you were to use a socket setup, similar to the example
that I posted, then the server would be notified of socket disconnection
Nothing in the sockets API makes that guarantee.
If it's a stream socket, over TCP, then if the client closes its end,
the client-side stack will try to send a FIN (or an RST, depending on
what kind of half-close the client does and other complications) to
the peer. That packet may or may not arrive. If it does, the
server-side stack will update its state, and report it to the server
in the appropriate manner. That's usually returning length 0 from a
receive operation, or returning the appropriate error indication from
a send operation.
could take appropriate action to quiesce whatever it was doing.
Not unless it checks, unless the server is using some mechanism (such
as Unix SIGIO) that lets the stack interrupt it. Also not part of the
sockets API, and completely outside the client's control.
What HTTP offers the client for aborting an operation on the server is
perfectly adequate for most purposes. Either the server pays attention
to the client's side of the connection, or it does not. Having the
client send an abort message on the HTTP request channel would add no
value; if the server's not checking that channel, it's not checking
that channel.
There are good reasons why HTTP does not use a separate control
channel (as eg FTP does). For one thing, it's a PITA for stateful
firewalls.
This is a slight simplification. There's no way for the server to
distinguish between a full, normal close by the client, and a client
half-close, except by trying to send data. In principle, a client
could send its request and then half-close the conversation, if it
doesn't want to send more data. However, RFC 2616 appears to encourage
servers to treat that as a full close:
-----
When a client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers SHOULD both
constantly watch for the other side of the transport close, and
respond to it as appropriate.
----- (8.1.4)
Since 2616 doesn't distinguish between half-close and full-close, it
appears that fully-compliant HTTP/1.1 servers have to detect a client
close of whatever sort (if possible) and terminate processing that
request.
That's already in the HTTP spec. There's no need to create another
protocol just to get that behavior, and as Jorge wrote, there's no
need for the client to do anything else. If the server is left
grinding, that's because the server isn't fully compliant with the
HTTP spec.
