Commit 1da7f1e2 authored by Brad Fitzpatrick's avatar Brad Fitzpatrick

net/http: comment handleReadError more, superficially use its argument

Fixes #24201

Change-Id: Ib970c4eeaa90489d014482276a7e5afa94a50741
Reviewed-on: https://go-review.googlesource.com/122675Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
parent cae5c7fe
...@@ -709,8 +709,17 @@ func (cr *connReader) setReadLimit(remain int64) { cr.remain = remain } ...@@ -709,8 +709,17 @@ func (cr *connReader) setReadLimit(remain int64) { cr.remain = remain }
func (cr *connReader) setInfiniteReadLimit() { cr.remain = maxInt64 } func (cr *connReader) setInfiniteReadLimit() { cr.remain = maxInt64 }
func (cr *connReader) hitReadLimit() bool { return cr.remain <= 0 } func (cr *connReader) hitReadLimit() bool { return cr.remain <= 0 }
// may be called from multiple goroutines. // handleReadError is called whenever a Read from the client returns a
func (cr *connReader) handleReadError(err error) { // non-nil error.
//
// The provided non-nil err is almost always io.EOF or a "use of
// closed network connection". In any case, the error is not
// particularly interesting, except perhaps for debugging during
// development. Any error means the connection is dead and we should
// down its context.
//
// It may be called from multiple goroutines.
func (cr *connReader) handleReadError(_ error) {
cr.conn.cancelCtx() cr.conn.cancelCtx()
cr.closeNotify() cr.closeNotify()
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment