Comment 1:

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

Status changed to Accepted.

Comment 2:

It's possible that people were calling tlsConn.Read(nil) for the side effect of doing
the TLS handshake and getting that error value.
Any fix (at least so late in Go 1.3) should probably preserve that property, like:
func (c *Conn) Read(b []byte) (n int, err error) {
        if err = c.Handshake(); err != nil {
                return
        }
        if len(b) == 0 {
        return
        }

Comment 3:

... then again, the Handshake method is public anyway, so I doubt Read(nil) was used
intentionally.

Comment 4 by aalevy:

Sounds reasonable to accommodate that anyway - it's the same number of
checks in the normal case and Handshake() is a noop if the connection has
been established. Should I send a change set?

Comment 5:

I agree that the behaviour should be the same, but I feel that it might be too late in
1.3 to fix this. I'm assuming that this behaviour of crypto/tls has been in there since
1.0.
I'll send out a patch if the decision is that this is 1.3 worthy.

Comment 6 by aalevy:

I'd (obviously) vote for including it in 1.3, especially with Brad's
suggested change:
1. It seems very unlikely that anyone is using crypto/tls this way with
the *expectation* that it will block.
2. If the check for zero-length is after the handshake check, it doesn't
break other reasonable current uses of tls.Conn#Read like checking for
an error in the handshake.

Comment 7:

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

Comment 8:

This issue was closed by revision 853c99d.

Status changed to Fixed.