| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +2 |
var (
wholeReqDeadline time.Time // or zero if none
)nit: Just `var wholeReqDeadline time.Time` now?
// Adjust the read deadline if necessary.nit: "if necessary" is no longer accurate now I think?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
wholeReqDeadline time.Time // or zero if none
)nit: Just `var wholeReqDeadline time.Time` now?
Done
nit: "if necessary" is no longer accurate now I think?
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Thank you Damien. I’ve left a few comments.
}1s timeout but the tests are in milliseconds and none of them including “header read expires” amount to more than the timeout, can we be explicit perhaps on the timeout?
t.Errorf("ReadAll from server: %v, want EOF", err)“want EOF” is very confusing, sure you want to read until the end of file but we have a common sentinel error EOF that isn’t relevant to this context. Perhaps: “ReadAll from server unexpectedly failed: %v”
if got, want := time.Since(start), srv.ReadHeaderTimeout; got != want {This seems like a fickle check that’ll flake, perhaps got < want? Is it because of synctest and fake time?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
1s timeout but the tests are in milliseconds and none of them including “header read expires” amount to more than the timeout, can we be explicit perhaps on the timeout?
The purpose of the sleeps in the tests is to demonstrate that they can't cause the timeout to extend past the defined 1s.
“want EOF” is very confusing, sure you want to read until the end of file but we have a common sentinel error EOF that isn’t relevant to this context. Perhaps: “ReadAll from server unexpectedly failed: %v”
We should read an EOF from the server (which ReadAll reports as nil).
if got, want := time.Since(start), srv.ReadHeaderTimeout; got != want {This seems like a fickle check that’ll flake, perhaps got < want? Is it because of synctest and fake time?
Not flaky. This runs in a synctest bubble with a fake clock; the timeout happens at precisely 1s or there's a bug.
Note that outside of a synctest bubble this would never pass, time.Since would always report that additional nanoseconds have passed since the timeout occurred.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
2 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: src/net/http/server.go
Insertions: 1, Deletions: 4.
@@ -570,11 +570,30 @@
}
}
-// disableWriteContinue stops Request.Body.Read from sending an automatic 100-Continue.
-// If a 100-Continue is being written, it waits for it to complete before continuing.
-func (w *response) disableWriteContinue() {
+// disableWriteContinue stops Request.Body.Read from sending an automatic
+// 100 Continue. As the name implies, it is only useful when the request
+// expects a 100 Continue and the body is wrapped in an expectContinueReader;
+// otherwise, it is a no-op.
+// If a 100-Continue is being written, it waits for it to complete before
+// continuing. If skipDrain is true, it also prevents the server from draining
+// the request body and flags the connection to be closed after the reply, as
+// the client will never send the body.
+func (w *response) disableWriteContinue(skipDrain bool) {
+ ecr, ok := w.reqBody.(*expectContinueReader)
+ if !ok {
+ return
+ }
w.writeContinueMu.Lock()
- w.canWriteContinue.Store(false)
+ if w.canWriteContinue.Load() {
+ w.canWriteContinue.Store(false)
+ if skipDrain {
+ // Make sure that the connection will not be reused by sending
+ // "Connection: close" header in the response.
+ w.closeAfterReply = true
+ // Ensure that the body will not be drained in Close.
+ ecr.closed.Store(true)
+ }
+ }
w.writeContinueMu.Unlock()
}
@@ -983,7 +1002,12 @@
}
func (ecr *expectContinueReader) Close() error {
- ecr.closed.Store(true)
+ if ecr.resp.canWriteContinue.Load() {
+ ecr.resp.disableWriteContinue(true)
+ }
+ if ecr.closed.Swap(true) {
+ return nil
+ }
return ecr.readCloser.Close()
}
@@ -1003,10 +1027,8 @@
return nil, ErrHijacked
}
- var (
- wholeReqDeadline time.Time // or zero if none
- )
t0 := time.Now()
+ var wholeReqDeadline time.Time // or zero if none
if d := c.server.ReadTimeout; d > 0 {
wholeReqDeadline = t0.Add(d)
}
@@ -1065,7 +1087,6 @@
body.doEarlyClose = true
}
- // Adjust the read deadline if necessary.
c.rwc.SetReadDeadline(wholeReqDeadline)
w = &response{
@@ -1178,10 +1199,12 @@
}
checkWriteHeaderCode(code)
- if code < 101 || code > 199 {
- // Sending a 100 Continue or any non-1xx header disables the
- // automatically-sent 100 Continue from Request.Body.Read.
- w.disableWriteContinue()
+ // Sending a 100 Continue or any non-1XX header disables the
+ // automatically-sent 100 Continue from Request.Body.Read. If it is a final
+ // response (200 or higher), we skip draining the request body, which the
+ // client will never send.
+ if code == 100 || code >= 200 {
+ w.disableWriteContinue(code >= 200)
}
// Handle informational headers.
@@ -1656,7 +1679,7 @@
if w.canWriteContinue.Load() {
// Body reader wants to write 100 Continue but hasn't yet. Tell it not to.
- w.disableWriteContinue()
+ w.disableWriteContinue(true)
}
if !w.wroteHeader {
@@ -1694,6 +1717,10 @@
w.conn.r.abortPendingRead()
+ if w.canWriteContinue.Load() {
+ w.disableWriteContinue(true)
+ }
+
// Close the body (regardless of w.closeAfterReply) so we can
// re-use its bufio.Reader later safely.
w.reqBody.Close()
@@ -1924,7 +1951,7 @@
}
if inFlightResponse != nil {
inFlightResponse.cancelCtx()
- inFlightResponse.disableWriteContinue()
+ inFlightResponse.disableWriteContinue(true)
}
if !c.hijacked() {
if inFlightResponse != nil {
@@ -2091,6 +2118,7 @@
// Wrap the Body reader with one that replies on the connection
req.Body = &expectContinueReader{readCloser: req.Body, resp: w}
w.canWriteContinue.Store(true)
+ w.reqBody = req.Body
}
} else if req.Header.get("Expect") != "" {
w.sendExpectationFailed()
@@ -2258,7 +2286,7 @@
if w.handlerDone.Load() {
panic("net/http: Hijack called after ServeHTTP finished")
}
- w.disableWriteContinue()
+ w.disableWriteContinue(false)
if w.wroteHeader {
w.cw.flush()
}
```
net/http: apply header timeout to server's unencrypted HTTP/2 check
When a server is configured to support unencrypted HTTP/2,
it reads a few bytes from each new connection to see if they
contain the HTTP/2 client preface. This read was being done
with no timeout applied. Apply the header timeout (since this
is essentially reading the first headers from the connection).
Hoist the header timeout into the server serve loop so we can
use a single timeout to cover both the HTTP/2 preface and
the first HTTP/1 headers.
Thanks to Vsevolod Naumov and Ainar Garipov from AdGuard for reporting this issue.
Fixes #80205
Fixes CVE-2026-56853
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |