how to make sure the http response was delivered?

Question

To respond a http request, we can just use return "content" in the method function.

But for some mission-critical use cases, I would like to make sure the http 200 OK response was delivered. Any idea?

Lavernalaverne

on_end_request? – Crispen

You likely would benefit from using something called MQTT. en.wikipedia.org/wiki/MQTT – Micahmicawber

Why wouldn't the client receive the response? HTTP runs on top of TCP which offers guaranteed delivery. If the connection itself drops or the client terminates the session before receiving the response, you should be able to detect at the server side. – Discernible

Answer 1

The HTTP protocol doesn't work that way. If you need an acknowledgement then you need the client to send the acknowledgement to you.

Or you should look at implementing a bi-direction socket (a sample library is socket.io) where the client can send the ACK. If it is mission critical, then don't let it be on just http, use websockets

Also you can use AJAX callbacks to gather acknowledgment. One way of creating such a solution would be UUID generated for every request and returned as a part of header

$ curl -v http://domain/url
....
response:

X-ACK-Token: 89080-3e432423-234234-23-42323

and then client make a call again

$ curl http://domain/ack/89080-3e432423-234234-23-42323

So the server would know that the given response has been acknowledge by the client. But you cannot enforce automatic ACK, it is still on the client to send it, if they don't, you have no way of knowing

PS: The UUID is not an actual UUID here, just for example shared as random number

Glucoprotein

Or, as an amalgam of the two, websockets. – Orangy

@tripleee, I meant to write websockets only. Thanks for your comment I just realized I ate the web :-) – Glucoprotein

@TarunLalwani, although I appreciate the help provided by the socket.io library, it should be noted that using socket.io is a convenience, not a requirement (and IMHO, your answer implies that it's a requirement). The use of AJAX and/or WebSockets can achieve the same result without requiring socket.io or any library. – Protocol

@Myst, see if the rephrased answer looks better – Glucoprotein

@TarunLalwani, Nice. I like the additions and the clarifications. The custom header approach was a nice touch. I already up-voted. – Protocol

I think the question is flawed to begin with. Why wouldn't the response be delivered if HTTP is running over TCP? – Discernible

@John, Not necessarily. Once the server has sent all the response data, there is some latency for the client to receive. In between a lot can happen. The client can disconnect, the network can disconnect, the network may have packet loss. So just because the server sent the response out, by no means assures the client did receive it – Glucoprotein

@TarunLalwani, if the client dropped before the response has been received, wouldn't the server detect that as some sort of I/O error since the TCP ACK for the response would have not been received? TCP was built specifically for that, i.e., "guaranteed delivery." Adding a hand-rolled ARQ layer on top of it doesn't make sense. – Discernible

Answer 2

Take a look at Microsofts asynchronous server socket.

An asynchronous server socket requires a method to begin accepting connection requests from the network, a callback method to handle the connection requests and begin receiving data from the network, and a callback method to end receiving the data (this is where your client could respond with the success or failure of the HTTP request that was made).

Example

Assignable

Answer 3

It is not possible with HTTP, if for some reason you can't use Sockets because your implementation requires HTTP (like an API) you must acknowledge a timeout strategy with your client.

It depends on how much cases you want to handle, but for example you can state something like this:

1. Client generate internal identifier and send HTTP request including that "ClientID" (like a timestamp or a random number) either in the Headers or as a Body parameter.
2. Server responds 200 OK (or error, does not matter)
3. Client waits for server answer 60 seconds (you define your maximum timeout).
   1. If it receives the response, handle it and finish.
   2. If it does NOT receive the answer, try again after the timeout including the same "ClientID" generated in the step 1.
      1. Server detects that the "ClientID" was already received.
         • Either return 409 Conflict informing that it "Already exists" and the client should know how to handle it.
         • Or just return 200 OK and the client never knew that it was received the first time.

Again, this depends a lot on your business / technical requirements. Because you could even get two or more consecutive loops of timeout handle.

Hope you get an idea.

Torry

Answer 4

as @tarun-lalwani already written is the http protocol not designed for that. What you can do is to let the app create a file and your program checks after the 200 respone the existence and the time of the remote file. This have the implication that every 200 response requires another request for the check file

Hermann