views:

522

answers:

5

I am writing a web server in Java and I want it to support HTTP 1.1 Keep-Alive connections. But how can I tell when the client is done sending requests for a given connection? (like a double end-of-line or something).

Lets see how stackoverflow handles this very obscure question -- answers for which, on Google, are mired in technical specifications and obscure language. I want a plain-english answer for a non-C programmer :)

A: 

You close it whenever you'd like. The header indicates that the client would prefer you to leave the connection open, but that doesn't require the server to comply. Most servers leave it open for about 5-10 seconds, some don't pay attention to it at all.

Stephen Deken
A: 

I see. that confirms my suspicion of having to rely on the SocketTimeoutException. But i wasn't sure if there was something i could rely on from the client that indicates it is done with the connection--which would allow me to close the connections sooner in most cases--instead of waiting for the timeout. Thanks

spiralhead
SocketTimeoutException only indicates that a read/accept operation on the socket timed out. The socket is still fine after the exception.
Alexander
A: 

You should read the RFCs dealing with the Keep-Alive feature. Otherwise you might end up with a server that doesn't work as expected.

As @[Stephen] has already pointed out, the server is free to close the connection anytime it wishes (ok, not in the middle of a request/response pair though). Ditto for the client. Any other solution would allow the server or the client to perform a DoS on the other party.

EDIT: Have a look at the Connection header. The client (and the server) can request a graceful connection closure using the header. For example, Connection: close inside the request is a request to the server to close the connection after it sends the response.

Alexander
spiralhead
The browsers prefer to keep their connection open because this increases the response time if they need to send more requests to the same servers. There's nothing preventing your server from ignoring the Keep-Alive feature and closing the connection after every request.
Alexander
+3  A: 

If you're building your server to meet the standard, then you've got a lot of information to guide you here already.

Simple spoken, it should be based on a time since a connection was used, and not so much at the level of request data.

In a longer-winded way, the practical considerations section of the HTTP/1.1 document has some guidance for you:

"Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server. The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client or the server."

or

"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. If a client or server does not detect the other side's close promptly it could cause unnecessary resource drain on the network."

Pete Karl II
spiralhead
+1  A: 

Lets see how stackoverflow handles this very obscure question -- answers for which, on Google, are mired in technical specifications and obscure language.

I just put When should I close an HTTP 1.1 connection? into Google, and the third hit was HTTP Made Really Easy. In the table of contents, there is a link to a section entitled Persistent Connections and the "Connection: close" Header. This section is three paragraphs long, uses very simple language, and tells you exactly what you want to know.

I want a plain-english answer for a non-C programmer :)

With all due respect, programming is a technical endeavour where the details matter a great deal. Reading technical documentation is an absolutely essential skill. Relying on "plain English" third-party interpretations of the specifications will only result in you doing a poor job.

Jim