Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: ResponseWriter leaves connection open after WriteTimeout #8534

Closed
jbardin opened this issue Aug 15, 2014 · 11 comments
Closed

net/http: ResponseWriter leaves connection open after WriteTimeout #8534

jbardin opened this issue Aug 15, 2014 · 11 comments
Milestone

Comments

@jbardin
Copy link
Contributor

jbardin commented Aug 15, 2014

go1.3.1

run the following http server:


```
package main

import (
    "fmt"
    "net/http"
    "time"
)

func handler(w http.ResponseWriter, r *http.Request) {
    time.Sleep(2 * time.Second)
    msg := []byte("Hello world!\n")
    n, err := w.Write(msg)
    fmt.Printf("Wrote %d out of %d bytes\n", n, len(msg))
    fmt.Println("Error was:", err)
}
func main() {
    http.HandleFunc("/", handler)
    server := http.Server{
        Addr:         ":8123",
        ReadTimeout:  time.Second,
        WriteTimeout: time.Second,
    }
    server.ListenAndServe()
}
```

What happens:

The Write always succeeds in this handler, and the connection is left open hanging the
client. 


What should happen:

- Connection closed due to timeout
- Preferably return an error when writes fail (though this may not be feasible due to
internal buffering)
@jbardin
Copy link
Contributor Author

jbardin commented Aug 15, 2014

Comment 1:

Sorry, pasted the incorrect Server: There should be no ReadTimeout in that snippet
    server := http.Server{
        Addr:         ":8123",
        WriteTimeout: time.Second,
    }

@ianlancetaylor
Copy link
Contributor

Comment 2:

Labels changed: added repo-main, release-go1.4.

@jbardin
Copy link
Contributor Author

jbardin commented Aug 15, 2014

Comment 3:

Seems to be related to keepalive. 
An HTTP1.1 connection hangs, but an HTTP1.0 connection is closed imediately. 
If you do run the first server code I posted with both timeouts, the client takes 3s to
return because the connection is left in keepalive, and the ReadTimeout is what shuts it
down.

@rsc
Copy link
Contributor

rsc commented Sep 16, 2014

Comment 4:

Brad, can you look at this?

Status changed to Accepted.

@griesemer
Copy link
Contributor

Comment 5:

Owner changed to @bradfitz.

@bradfitz
Copy link
Contributor

bradfitz commented Oct 2, 2014

Comment 6:

Found it. There are dozens of writes that don't check the error return value. It's
almost always fine because they're buffered, but you never know where a buffer boundary
will be. Some Flushes weren't checking either.
Note to self: the easiest fix is something like https://golang.org/cl/149340044
which catches them all. Needs tests.

Status changed to Started.

@rsc
Copy link
Contributor

rsc commented Oct 15, 2014

Comment 7:

Brad, still working on this?

@bradfitz
Copy link
Contributor

Comment 8:

Issue #8648 has been merged into this issue.

@gopherbot
Copy link

Comment 9:

CL https://golang.org/cl/149340044 mentions this issue.

@bradfitz
Copy link
Contributor

Comment 10:

This issue was closed by revision 9d51cd0.

Status changed to Fixed.

@bradfitz
Copy link
Contributor

Comment 11:

Issue #8648 has been merged into this issue.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants