In HTTP/1.1 (persistent connections), what is the "signal" which prompts the client to send the next HTTP request? Is there anything else besides Content-Length?
I'm trying to build a simple gateway, which would bridge the TCP traffic across files. I have two apps:
- "server" opens a socket and waits for connections. When the connection is established it forwards everything it gets ot the output file, at the same time forwarding everything from input file back to the socket
- "client" waits for content in the above output file and makes the connection to the server, sends data to it and writes the received data back to the above input file.
In other words: everything I get through socket is redirected through files to another socket, and vice versa.
AFAIK this should be completely transparent, but persistent connections do not work as expected.
I am testing with Firefox - what happens is that FF sends two GETs and receives two responses. But then it just sits there and waits as if it hasn't received all data yet... After 5 seconds (server responds with "Keep-Alive: timeout=5", so this fits) one of the sides closes the connection and reestablishes it and sending continues for a few files, when it gets stuck again.
I have listened with WireShark, but could not spot anything out of ordinary. Any idea what is going on?
UPDATE: below is a screenshot of WireShark log. It shows that the HTTP connection is sent much too late, after TCP connections closes (notice the times). Judging from my logs it was sent right away. Any idea why this discrepancy? Should I "flush" the socket somehow? I'm using Python.
