HTTP: error during response after 200 status code OK

Question

As an HTTP 1.1 server, I respond to a GET request with a status code of 200 OK, and then send the data to the client. An error occurs during this submission, and I cannot finish.

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

How should I behave to inform the client about the error, and I can not continue this HTTP request?

I can only think of one solution: close the socket, but it is not perfect: it interrupts the keep-alive function, and a clear explanation of the error is not provided to the client.

The HTTP standard seems to assume that the server already knows exactly what to respond before it starts to respond. But it's not always the case. Examples: I am returning a very large file (several GB) from the disk, and I am getting an I / O error at some point while reading the file. The same example with a large dump of DB.

I cannot build my entire answer in memory and then send it.

The HTTP 1.1 standard helps for this use with packet-encoded encoding: I don’t even need to know the final size before starting to send a response. Therefore, this use is not excluded from HTTP 1.1.

Answer 1

Finally, I found a possible solution for this: HTTP 1.1 Trailer Headers .

In encoded encoded bodies, HTTP 1.1 allows the sender to add data after the last (empty) fragment as a block of headers. The specification hints at some use cases, such as calculating the body's md5 on the fly, and sending it after the body so that the client can verify its integrity.

I think it can be used for error messages, even if I did not find anything about this use.

The problems that I see with this:

• this requires the use of encoded encoding (but this is not a big problem)
• trailer support is probably very low:
  • on the server side (you can bypass it manually by creating encoded encoding, but since it is applied after encoding the content (gzip), this will require a lot of re-implementation)
  • on the client side (errors fixed only in 2010 in curl , for example)
  • and on proxies (which could then lose trailers if they were not properly implemented)

Answer 2

I picked up a similar question that needs to be answered, so you can find that there is no solution :

How to say that something is wrong with the server during a response that started with 200 OK. Fault tolerant