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?

Solution 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.

Solution 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.

Solution 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.

Solution 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.

View more solutions

Comments

[TheChetan]

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.

[Davis Herring]

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

[TheChetan]

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

[Damien_The_Unbeliever]

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

[Jesse Chisholm]

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.

[Enda Farrell]

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.

[zolty13]

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