When responding using io.Copy, who should be responsible for the error?

Assume that the server needs to respond with some data to the client and the data comes from a file on a local disk. Then we write,

n, err := io.Copy(w, f)  // w is the ResponseWriter and f is the *os.File

What I'm thinking is, io.Copy() first writes a header and then copies data from f to w.

When err is not nil (say unexpected EOF), the client still gets a status code 200, although the response body contains something wrong.

Maybe the local disk is broken, or maybe the client's network is broken. How can we determine
whether the err is caused by the server or the client?

io.Copy calls Write on the target io.Writer. http.ResponseWriter's documentation on the Write method specifies this behaviour:

// Write writes the data to the connection as part of an HTTP reply.
// If WriteHeader has not yet been called, Write calls WriteHeader(http.StatusOK)
// before writing the data.  If the Header does not contain a
// Content-Type line, Write adds a Content-Type set to the result of passing
// the initial 512 bytes of written data to DetectContentType.
Write([]byte) (int, error)

That means it will first call WriteHeader:

// WriteHeader sends an HTTP response header with status code.
// If WriteHeader is not called explicitly, the first call to Write
// will trigger an implicit WriteHeader(http.StatusOK).
// Thus explicit calls to WriteHeader are mainly used to
// send error codes.
WriteHeader(int)

So yes, if your HD was to fail somewhen during a Write operation you'd already have written a 200 OK response, however, if your response specifies a Content-Length the client will know something is wrong when your response's length doesn't match.

In the case of HTTP 1.1 and chunked transfer encoding you would theoretically be able to specify a failure header after the response in an HTTP trailer. Regretfully though, HTTP trailers are not supported by any of the current most used web browsers.

Contribution from @OneOfOne: io.Copy's error will not specify which end failed; if server or client.

> So as a result, we can't point out the err should be logged as 4xx or 5xx, right?

If you're logging an HTTP status header then log what you sent your client as a response; not what it should have been.

When copying directly from the file to the response writer, the only way to tell the client that something is wrong is to send an incomplete response body.

To force the server to send an incomplete response body, specify the content length before copying the body:

 w.Header().Set("Content-Length", strconv.Itoa(fileLen))

The handler should simply return after copying the body, error or not.

The server checks to see if the handler wrote the number of bytes specified in the content length header. If the handler did not write that number of bytes, then the server closes the connection.

The client can detect that the connection was closed before the complete body was read. Many HTTP client libraries will report an error in this scenario.

If you buffer the file in memory before starting to write the response, then you can set the response status code to indicate an error. If the file is large, you may not want to buffer.

It's difficult for the handler to detect if the io.Copy failed due to an error reading the file or an error writing to the client. Given the number of possible code paths involved (different OS's, TLS or not, optional optimizations in io.Copy, ...), there are many potential errors returned from io.Copy. The errors may not even be unique between file and client errors.

Specifying the content length before copying the file has additional benefits: The server always uses the most efficient transfer encoding (the identity encoding) when the content length is known. On some operating systems, the io.Copy operation will be done by the kernel.