0

I want to create keep-alive connection, which should not close. I tried below way but it is closing after date get printed.

public class SimplePHTTPServer {
  public static void main(String args[]) throws IOException {
    ServerSocket server = new ServerSocket(1122);
    System.out.println("Listening for connection on port 1122 ....");
    while (true) {
      try (Socket socket = server.accept()) {
        Date today = new Date();
        String httpResponse = "HTTP/1.1 200 OK\r\n\r\n" + today;
        socket.getOutputStream().write(httpResponse.getBytes("UTF-8"));
        Thread.sleep(5000);
      } catch (InterruptedException e) {
         e.printStackTrace();
      }
    }
  }
}

Tested through curl below is the actual output:

curl -i -X GET -H "Connection: keep-alive" http://localhost:1122/

HTTP/1.1 200 OK

Thu Aug 02 18:42:30 IST 2018

expected result is :

curl -i -X GET -H "Connection: keep-alive" http://localhost:1122/

HTTP/1.1 200 OK

Thu Aug 02 18:42:30 IST 2018

Thu Aug 02 18:47:30 IST 2018

Thu Aug 02 18:52:30 IST 2018

... so on

How to create keep-alive connection?

Rajesh Narravula
  • 1,433
  • 3
  • 26
  • 54
  • I worked on a similar issue about a year ago. We decided this was not an optimal approach as there invariably seemed to be something that would disrupt the connection that was out of our control on the network between points. In our case, we went with a push notification model instead which was much more natural. Depending on your use case, you could also look at streaming if you really need a constant stream of data, though even then you may experience times when the connection is disrupted. We also saw memory issues with leaving sockets open but that could be a number of things. – J E Carter II Aug 02 '18 at 13:49

1 Answers1

0

You mistake the purpose of the persistent connection. It allows you to make multiple requests and get multiple responses over one connection.

In your test, you send one request and you're trying to provide an unlimited length response body.

The way you try to provide unlimited length response body is not correct. Please read this RFC, paying special attention to "transfer coding". Some choice quotes:

Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0 experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify these problems.

...

Persistent connections are the default for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for declaring non-persistence. See section 14.10.

...

7.2.2 Entity Length

The entity-length of a message is the length of the message-body before any transfer-codings have been applied. Section 4.4 defines how the transfer-length of a message-body is determined.

...

4.4 Message Length

The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):

...

2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.

3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self- elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte- range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.

A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server MUST delimit the message using methods defined in items 1,3 or 5 of this section.

5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)

Community
  • 1
  • 1