This repository has been archived by the owner on Sep 17, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 134
Server.handleConn hangs #53
Comments
@bradfitz, do these new bugs look legit to you? |
Yes, there are wrong assumptions of the API contact between the Framer and the server loop around what type of errors can be returned. Stream-level errors are being lost and causing these problems. I just haven't had time to fix yet. |
Fix out for review: https://go-review.googlesource.com/15735 |
c3mb0
pushed a commit
to c3mb0/net
that referenced
this issue
Apr 2, 2018
There was a design problem earlier where the serve goroutine assumed that the readFrame goroutine could return only connection-level errors, but the readFrames goroutine (and the underlying Framer) assumed it could return stream-level errors (type StreamError) and have them handled as stream errors in the layers above. That's how it should have been, and what this CL does. Now readFrames returns both the Frame and error from ReadFrames together as a pair, and an error isn't necessarily fatal to the connection. Fixes golang/go#12733 Fixes bradfitz/http2#53 Change-Id: If4406ceaa019886893d3c61e6bfce25ef74560d3 Reviewed-on: https://go-review.googlesource.com/15735 Reviewed-by: Dmitry Vyukov <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The following test hangs in Server.handleConn while the connection is already effectively closed.
on commit 8348f2f
The text was updated successfully, but these errors were encountered: