8

A third party that is going to make HTTP requests to the API that I'm building, requires that the API responds in less than one second. My question is, do they have a way (literally any way, within the bounds of the http and/or tcp/ip protocols) to abort the execution of my code if it takes longer than one second?

Improve this question
8
  • 1
    They can set the timeout of the HttpClient directly, but that does not abort the code running on the server side.
    – Jon Raynor
    Dec 11, 2017 at 20:31
  • 17
    Yes. IP geolocation and a cruise missile. If that's not what you had in mind, you will have to get a lot more precise with your "literally any way".
    – Jörg W Mittag
    Dec 11, 2017 at 20:39
  • There could tens reasons that could "make belive" the user that the process is taking longer than 1 second. For example, latency. You know, someone in the office downloading suspicious content... By the time the user send the cancel request, the process could have finished successfully. 1 second is to little time (I think) for a human.
    – Laiv
    Dec 11, 2017 at 21:08
  • @jmoreno does your "bounds" include me adding a cancel button for the user to click? Or are you looking for something lower in the osi stack than the application layer?
    – candied_orange
    Sep 22, 2018 at 16:51
  • 2
    Surprised this was VTC'd actually. The answer is sure. Nothing prevents you from registering requests in some way and adding an endpoint or API method that cancels them -- either through native process management or by having "cancellable" requests periodically check if they've been instructed to stop...
    – svidgen
    Sep 22, 2018 at 16:57

2 Answers 2

Reset to default
12

HTTP doesn't work like that. The client sends a request, then the server sends a response back. No other communication occurs. Well, the server can send 1xx informational responses before the main response. But there is no way for the client to send updates about a sent request.

(The situation is very different for HTTP/2 which can multiplex multiple requests over the same connection. A client can CANCEL a stream to indicate that it is no longer needed after it receives a PUSH_PROMISE from the server. I'll ignore HTTP/2 for the rest of this answer.)

Also, networks don't work like that. In particular, see the second fallacy of distributed computing: “latency is zero”. It is not. Of that one second timeout, 400ms may have been spent on establishing the connection and sending the request and 600ms on the response, because one of the packets was dropped and you had to resend everything and your client is in Australia. Aside from the problem that the server might not have enough time, the server doesn't even know how much time they have because response latency cannot be known in advance.

So given that literally implementing these timeouts is impossible, what kind of solution might be good enough?

If the response will have no value after the timeout, the client can simply close the connection. This will cause your response to be ignored, but will not prevent the response.

Closing the TCP connection over which the HTTP request is sent does notify the server. But this notification only arrives with latency, so it may be too late. Also, your web framework may not be doing anything when the client socket is closed. In that case you'd only get an error “connection reset by peer” once you try to write to the closed socket.

If you do not want to spend more than one second on processing for the response, implementing that timeout is entirely your responsibility, and has nothing to do with networking or HTTP.

You can ask the client to provide a timeout to the server, so that the server can abort if it cannot meet the deadline. This could be specified as a custom header, or as a query parameter in the URL. This deadline should be an absolute point in time and not a duration so that transmission delays also consume the available time. But sub-second accuracy is difficult: the server and the client need to be synchronized with the correct time and need to use a suitable clock. Depending on the setup each time source may be off by 100ms even when configured correctly. This already eats a significant chunk of your time budget.

Improve this answer
1
  • Of course you can send a timeout as relative time - it just means the server cannot stop processing x seconds after you send the request, but only x seconds after the server received it. May be better if you cannot guarantee that your clock and the server clock are the same. If they are two minutes apart, all requests with a one minute timeout (in absolute time) might be rejected.
    – gnasher729
    Sep 22, 2018 at 16:19
1

I suppose they could close the connection, but I don't know if that would actually cause your code to abort - it would depend on how your code is written.

They could also send another message that could mean "you're taking too long so don't bother" but in that case, you'd probably already be prepared to handle an explicit CANCEL_REQUEST message.

Improve this answer
1
  • I think writing to a closed port will signal, but you can of course ignore or handle that signal (I only know this from the client side, where this problem would make the client crash if you don't handle it). Apart from that, the client cannot FORCE the server to do anything. Of course the server can abort its work voluntarily if the port is closed, or abort work if it's not going to be done within the timeout, or abort work if the client sends a message to cancel the request.
    – gnasher729
    Sep 22, 2018 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.