Because reads are blocking and, by definition, a stream will remain open until either server or client closes them, we don't seem to have a good mechanism to ensure no bytes are left unread from the HTTP response body when the client decides to terminate the stream. On the other hand, this issue only seems to affect HTTP/1.x connections.
I've validated that the go driver prefers HTTP/2.x in prod so, I'm inclined to document this behaviour in case anyone is using it behind an HTTP/1.x proxy instead of trying some complex/unreliable mechanism to ensure clean connection termination at this point.
Because reads are blocking and, by definition, a stream will remain open until either server or client closes them, we don't seem to have a good mechanism to ensure no bytes are left unread from the HTTP response body when the client decides to terminate the stream. On the other hand, this issue only seems to affect HTTP/1.x connections.
I've validated that the go driver prefers HTTP/2.x in prod so, I'm inclined to document this behaviour in case anyone is using it behind an HTTP/1.x proxy instead of trying some complex/unreliable mechanism to ensure clean connection termination at this point.