Detecting missing responses to long running HTTP (SOAP) requests

Question

I need a way to detect a missing response to a long running HTTP POST request. This problem arises when the network infrastructure (firewalls, proxies, unplugged cables, etc.) drops the response packets. The server may detect this failure, but the client cannot send additional bytes after the POST to probe the state of the TCP connection. The failure may be limited to a single TCP connection. For example I may be able to subsequently open a new TCP connection to the server.

I'm looking for a solution that still uses HTTP POST and does not change the duration of the server side processing.

Some solutions that I can think of are:

1. Provide a side channel interface to retrieve request & response history. If the history lists the response as having been send (presumably resulting in a TCP error) but I have not yet received it within a reasonable time I can generate a local error.

2. Use an X header to request that the server deliver "spurious" 100 Continue provisional responses on a regular interval. If I fail to see an expected 100 Continue or a non-provisional response I can generate a local error.

Is there a state of the art solution for this problem?

Answer 1

It sounds to me like you are using Soap for something that would be much better done using a stateful connection, or a server side push technology.