What is the Correct HTTP Status Code for a Cancelled Request

Question

When a TCP connection gets cancelled by the client while making a HTTP request, I'd like to stop doing any work on the server and return an empty response. What HTTP status code should such a response return?

Dyspnea

When a request gets canceled, will the client read the sever response? What exactly do you mean by "canceled"? What have you tried? Why are there ten "My situation is unique, tell me which of the 20 or so status codes I should use" questions per day? Does it really matter? – Pileup

It does still matter because caches, browser developer tools and other intermediaries still read the response. So far, I'm just using a 400 Bad Request but that feels wrong. This is not a unique situation and I was surprised that an answer did not already exist. Status codes are all about language which is why it's difficult to know which to use. The language you use in your API/site is important as it conveys intent. If my browser cancels a request and I see a 400 Bad Request in the F12 developer tools, this suggests that the request was invalid which is the incorrect intent. – Dyspnea

There's no ability within HTTP for a client to cancel a request. So it's not surprising that no code is defined for the server to return. – Raeraeann

I think it's very important to consider why the request is cancelled, rather then just look for one specific code for any request being cancelled. – Euphorbia

If the server can still send, then it can send any response it wants, including the complete repose requested. The client cancelling (closing its sending half) just means the server will not receive any more data from the client. The client may continue to receive the rest of the result from the server. ON THE OTHER HAND, if the client closes both halves of the socket, then the server gets an error when next it does anything with that socket and recovers with no need to send anything more the the client. – Depreciatory

The only means the server has for detecting a cancelled request is by attempting to send a response: by which time the response code is ipso facto already determined. And the only means a client has for cancelling a request is to close the connection: which means it cannot receive any response at all. So, at the most basic level, your question does not make any sense. – Rarely

Answer 1

To be consistent I would suggest 400 Bad Request now if your backend apps are capable of identifying when the client gets disconnected or if you reject or close the connection, probably you could return Nginx' non-standard code 499 or 444.

• 499 Client Closed Request Used when the client has closed the request before the server could send a response.

• 444 No Response Used to indicate that the server has returned no information to the client and closed the connection.

Brambly

204 No Content: The server successfully processed the request and is not returning any content. Also seems to fit the OPs theme quite nicely. – Ochs

No Content does not fit to timeout. 204 indicate that something might changed on the server side e.g. entity was updated – Crossgrained

499 should not be used. I couldn't find any official documentation mentioning 499 returned by nginx, plus another is using it for something else: en.wikipedia.org/wiki/… – Karaite

Answer 2

HTTP (1.0/1.1) doesn't have a means to cancel a request. All that a client can do if it no longer wants the response is to close the connection and hope that the server contains an optimization to stop working on a response that can no longer be delivered. Since the connection is now closed, no response nor status code can actually be delivered to the client and so any code you "return" is only for your own satisfaction. I'd personally pick something in the 4xx range¹ since the "fault" - the reason you can no longer deliver a response - is due to the client.

HTTP 2.0 does allow an endpoint to issue END_STREAM or RST_STREAM to indicate that they are no longer interested in one stream without tearing down the whole connection. However, they're meant to just ignore any further HEADERS or DATA sent on that stream and so even though you may theoretically deliver a status code, the client is still going to completely ignore it.

---

¹Probably 400 itself since I can't identify a more specific error that seems entirely appropriate.

Raeraeann

Seems relevant en.wikipedia.org/wiki/HTTP_451: A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource. – Ochs

@TheChetan: That's for censorship, not asynchronous cancellation. – Pournaras

@Ochs - and again, the context here seams to be "cancellation" from the client rather than the server - which of course isn't an HTTP concept. – Raeraeann

Even in the old days (HTTP 1.x) you can close the sending half of your socket, and leave the receiving half open. The server gets the close, but it can still send a response if it wants to. – Depreciatory

Answer 3

There are just a few plausible choices (aside from 500, of course):

1. 202 Accepted

   You haven't finished processing, and you never will.

   This is appropriate only if, in your application domain, the original requestor "expects" that not all requests will be satisfied.

2. 409 Conflict

   …between making and cancelling the request.

   This is only weakly justified: your situation does not involve one client making a request based on out of date information, since the cancellation had not yet occurred.

3. 503 Service Unavailable

   The service is in fact unavailable for this one request (because it was cancelled!).

The general argument of "report an error as an error" favors 409 or 503. So 503 it is by default.

Pournaras

5xx are for server-side errors. If the client cancels, we should not give any indication that the server errored unless it did. I think 4xx makes much more sense – Karaite

Answer 4

There really is little to do. Quoting from RFC 7230, section 6.5:

A client, server, or proxy MAY close the transport connection at any time.

That is happening at TCP-, not HTTP-level. Just stop processing the connection. A status code will confer little meaning here as the intent of an incomplete/broken request is mere speculation. Besides, there will be no means to transport it across to the client.

Malefactor

While the client won't receive this status code, your logging/metrics-gathering should and there are many cases when knowing that the response wasn't finished as the client cancelled is important when figuring out how to make the service/server better. – Swound

Answer 5

I guess this will always be subjective, but another option which I think makes sense and I don't think has been mentioned yet is 408 Request Timeout. From https://http.dev/408:

When the 408 Request Timeout error message is received, it means that a client has initiated a request but for some reason, it has not been transmitted in full. This may occur because an internet connection is very slow, or has been dropped. The response will include the Connection header, specifying that it has been closed.

Defy

Answer 6

I was wondering the same thing as OP. To be honest, there is no right answer to that because it is not regulated by any means. The cancelled request will never reach the client but if you have some more complex proxy routing set to your server, such a response could be visible on logs, so I will go with something easy to find as 418 I'm a teapot

Cutup