2

I've observed a HTTP 1.1 Server implementation, which terminates a client connection as soon as it detects a client-side connection shutdown of its outgoing channel (or rather, either before or after sending a proper http response). Is this a conforming HTTP 1.1 implementation?

RFC 2616 Section 8.1.4 seems to suggest this is to be the proper behaviour:

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.

...

Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.

Am I interpreting it right? Is there a more explicit reference about half-closed connection handling in the context of HTTP 1.1?

hvr
  • 7,775
  • 3
  • 33
  • 47

1 Answers1

1

As far as i know, thats is all we need to know about Half-closed connections.

The server will only close the connection if it detects that the client closed it (it can ben when the server is about to write to the socket) or at the end of the request, if it does not support connection: keep-alive.

The client can disconnect any time, but it should tell the server why is it disconnecting (time_out, request cancel). But it is not very used by those who write sockets components. They just close the socket when they need to force a time_out.

But the client implementation is not the problem. You should worry about server implementation since suffer a lot with those unexpected disconnects.

EDIT

Maybe those links can help you.

Transmission Control Protocol - Functional Specification

TRANSMISSION CONTROL PROTOCOL

Rafael Colucci
  • 6,018
  • 4
  • 52
  • 121
  • ...so what are you saying w.r.t. to the original question, whether a conforming HTTP 1.1 server is allowed to terminate the connection (by sending a `FIN`) -- before any HTTP response was sent -- on reception of a `FIN` packet from the client? – hvr Mar 30 '11 at 10:21
  • How does a HTTP client tell the server the reason why it is disconnecting? Is this part of the HTTP specification, where can I find out more about that? – hvr Mar 30 '11 at 10:24
  • The client does not say why is it disconnecting. It just starts the disconnect handshake (sending fin, syn, etc) and then it disconnects. This is the right way to disconnect, but sometimes it can simple disconnect without sending anything to the server. If you wanna know why is the client disconnecting, you have to implement it by yourself (but it is not part of the HTTP specification). – Rafael Colucci Mar 30 '11 at 12:09
  • There are some ways the server can disconnect. It can, as you said, before sending the response to the server, detect a FIN sent by the client and disconnect. It can also disconnect at the moment it is going to write to the socket, and it detects that the client is no longer responding. And last, it can in the end of the request when it detects that the client does not support keep-alive. Of course, it can disconnect if you tell it to do so. – Rafael Colucci Mar 30 '11 at 12:12