I believe this happens when the image server experiences an error decoding, which is typically due to a connection being broken mid-download (closing a browser tab, OpenSeadragon timing out, etc.). Since the first call to Write causes net/http to spit out all headers, an error during that write cannot be propagated in said headers.
At a minimum, errors during the "write to client" phase shouldn't try to re-send headers. However, removing that behavior doesn't actually fix the problem entirely.
Despite this error currently happening only due to client behaviors, the real solution is to verify that the decode works separately from writing out to the client. In the (granted, unlikely) situation that a decode operation fails, that error should be separate from errors writing to the client. The downside here is that we'd need to write to a temporary buffer instead of being able to just stream to the client. For large operations, like full- or max-image requests, this could explode RAM usage.
jechols
commented
6 years ago
I believe this happens when the image server experiences an error decoding, which is typically due to a connection being broken mid-download (closing a browser tab, OpenSeadragon timing out, etc.). Since the first call to Write causes net/http to spit out all headers, an error during that write cannot be propagated in said headers.
At a minimum, errors during the "write to client" phase shouldn't try to re-send headers. However, removing that behavior doesn't actually fix the problem entirely.
Despite this error currently happening only due to client behaviors, the real solution is to verify that the decode works separately from writing out to the client. In the (granted, unlikely) situation that a decode operation fails, that error should be separate from errors writing to the client. The downside here is that we'd need to write to a temporary buffer instead of being able to just stream to the client. For large operations, like full- or max-image requests, this could explode RAM usage.