6

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?

Kevin Kuei
  • 193
  • 2
  • 17
  • [`on_end_request`](http://docs.cherrypy.org/en/latest/extend.html#hook-point)? – webknjaz -- Слава Україні Mar 23 '18 at 14:45
  • You likely would benefit from using something called MQTT. https://en.wikipedia.org/wiki/MQTT – applecrusher Apr 18 '18 at 16:44
  • 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. – MEE Apr 18 '18 at 17:30

4 Answers4

13

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

Tarun Lalwani
  • 142,312
  • 9
  • 204
  • 265
  • Or, as an amalgam of the two, websockets. – tripleee Apr 19 '18 at 05:05
  • @tripleee, I meant to write `websockets` only. Thanks for your comment I just realized I ate the `web` :-) – Tarun Lalwani Apr 19 '18 at 05:33
  • @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. – Myst Apr 19 '18 at 06:23
  • @Myst, see if the rephrased answer looks better – Tarun Lalwani Apr 19 '18 at 06:29
  • @TarunLalwani, Nice. I like the additions and the clarifications. The custom header approach was a nice touch. I already up-voted. – Myst Apr 19 '18 at 06:32
  • I think the question is flawed to begin with. Why wouldn't the response be delivered if HTTP is running over TCP? – MEE Apr 19 '18 at 15:03
  • @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 – Tarun Lalwani Apr 19 '18 at 15:13
  • @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. – MEE Apr 19 '18 at 16:07
1

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

Jesse Milam
  • 66
  • 4
1

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.

Jorge Sampayo
  • 838
  • 9
  • 24
0

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

Aleksandar
  • 2,442
  • 3
  • 15
  • 24