0

I am wondering how to properly manage the following HTTP response considering the file I am sending to the client contains other linked files representing future HTTP requests.

I know that I can close the PrintWriter which will indicate to the client that the body is finished, but if I do that I don't see how I can receive subsequent requests for the linked pages within "first.html". I tried to include the content-length header but it seems I may have calculated the length incorrectly as any attempt to read from the input stream after sending "first.html" block/stall. Which tells me the client doesn't realize that the first.html file has finished sending. I've read over RFC 2616 but frankly have trouble understanding it without a proper example. I'm a real child when it comes to protocols, so any help would be appreciated!

public static void main(String[] args) throws Exception{
    ServerSocket serverSocket = new ServerSocket(80);
    Socket clientSocket = serverSocket.accept();
    BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); 
    PrintWriter out = new PrintWriter(clientSocket.getOutputStream(),true);   

    String s;
    while (!(s = in.readLine()).isEmpty()) {
        System.out.println(s);
    }

    out.write("HTTP/1.0 200 OK\r\n");
    out.write("Content-Type: text/html\r\n");
    out.write("Content-Length: 1792\r\n");
    out.write("\r\n");


    File html = new File("/Users/tru/Documents/JavaScript/first.html");
    BufferedReader htmlreader =  new BufferedReader(new InputStreamReader(new FileInputStream(html)));

    int c;
    while((c = htmlreader.read()) > 0){
        out.write(c);
    }
}
Truman Purnell
  • 253
  • 3
  • 9
  • Possible duplicate of [A Simple Http Server with Java/Socket?](http://stackoverflow.com/questions/10788125/a-simple-http-server-with-java-socket) – Steffen Ullrich Jan 28 '17 at 19:00
  • @SteffenUllrich Haha man I've scoured that question. They close the output stream.I wanna know how to keep reading from the requests THAT response yields – Truman Purnell Jan 28 '17 at 20:56
  • You only say that you want to handle following requests and not that this must be within the same TCP connection. You are currently doing a HTTP/1.0 response without specific Connection header which means that the client will not do any HTTP keep-alive. This means that the new request will be done within a new TCP connection so your code has to deal with new TCP connections. And even if you manage to send back the information that you support keep-alive the client might still use a new TCP connection because HTTP keep-alive is just a suggestion and not an order. – Steffen Ullrich Jan 28 '17 at 21:04
  • @SteffenUllrich my problem remains even when changed to HTTP/1.1. I'm not smart enough to get this working, I need help. – Truman Purnell Jan 28 '17 at 21:12
  • Again, you *must* to be able to deal with multiple TCP connections. As for multiple requests inside the same TCP connection: the seconds request is just like the first, i.e. as long as your HTTP response did properly end (it's unknown if your content-length is correct) you can just restart with reading the new request the same way as you did with the first. – Steffen Ullrich Jan 28 '17 at 21:26
  • @SteffenUllrich I really appreciate your help and now understand well what you are saying. I am having issues calculating the content-length header. Java's .length property for a file still left my second read request blocking? – Truman Purnell Jan 28 '17 at 21:34
  • The problem might be that you are combining `readline` with `write`. According to [the documentation](https://docs.oracle.com/javase/7/docs/api/java/io/BufferedReader.html#readLine()) `readline` returns the line *without* the line ending so you actually don't write out the full line but the line without line end. Then of course the content-length does not match. I suggest that you use `read` and not `readline` instead. But even if you fix it there is still no guarantee that the next request will be done inside the same TCP connection. – Steffen Ullrich Jan 28 '17 at 21:49
  • @SteffenUllrich I like the thinking, but unfortunately your intuition was true. Even with `read`, subsequent requests within the same TCP Connection block and do not read. This is where my knowledge breaks down and the answers are tricky to find. Any idea why one TCP connection cannot continue to read as many times as needed? It must be a content length error but I checked that. See edited code. That is, if this interests you :) – Truman Purnell Jan 29 '17 at 00:19
  • You don't show any code how you compute the content-length so it might simply wrong. Apart from that I repeat it again: HTTP keep alive is only a suggestion and not an order. Even if HTTP keep alive is properly supported by the server the client is free to do the next request inside a new TCP connection so you MUST support this case which you currently don't. – Steffen Ullrich Jan 29 '17 at 06:48

0 Answers0