HTTP: error during reply after 200 OK status code

Question

As an HTTP 1.1 server, I reply to a GET request with 200 OK status code, then start sending the data to the client. During this send, an error occurs, and I cannot finish.

I cannot send a new status code as a final status code has already been sent.

How should I behave to let the client know an error occurred and I cannot continue with this HTTP request?

I can think of only one solution: close the socket, but it's not perfect: it breaks the keep-alive feature, and no clear explanation of the error is given to the client.

The HTTP standard seems to suppose that the server already knows exactly what to reply before it starts replying. But this is not always the case. Examples: I return a very large file (several GB) from disk, and I get an IO error at some point during the reading of the file. Same example with a large DB dump.

I cannot construct my whole response in memory then send it.

The HTTP 1.1 standard helps for such usage with the chunked transfer encoding: I don't even need to know the final size before starting to send the reply. So these usage are not excluded from HTTP 1.1.

Answer 1

I have pushed the similar question to be answered, so here you can find that there is no solution:

How to tell there's something wrong with the server during response that started as 200 OK. Fail gracefully

Answer 2

I finally found a possible solution for this: HTTP 1.1 Trailer headers.

In chunked encoded bodies, HTTP 1.1 allows the sender to add data after the last (empty) chunk, in the form of a block of headers. The specification hints some use-cases like computing on the fly a md5 of the body, and send it after the body so the client can check its integrity.

I think it could be used for error reporting, even if I haven't found anything about this kind of usage.

The issues I see with this are:

• this requires using chunked encoding (but it's not much of an issue)
• trailers support is probably very low:
  • server-side (it could be bypassed by manually creating the chunked encoding, but since it's applied after the content-encoding (gzip), it would require a lot of reimplementation)
  • client-side (bugs fixed only in 2010 in curl for example)
  • and on proxies (that could then loose the trailers if not properly implemented)