I mean, we could do something here and record the first few bytes before giving it to crypto/tls. And then when crypto/tls gives us an error, we could look at the bytes we copied and see if it looks like "HTTP/*" and return a better error.

Pretty low priority, but a fine feature request.

Yes that would be a lot more helpful.

I lost a good half-an-hour trying to pin point the problem. @minux suggestion would send me immediately in the right direction.

Thanks

Turns out this is pretty easy to propagate. crypto/tls returns an untyped fmt.Errorf error, so we can make it a real type with the data. The data is easily accessible.

diff --git a/src/crypto/tls/conn.go b/src/crypto/tls/conn.go 
index e3dcf15..2a41beb 100644
--- a/src/crypto/tls/conn.go
+++ b/src/crypto/tls/conn.go
@@ -568,7 +568,7 @@ Again:
        }
        if n > maxCiphertext { 
                c.sendAlert(alertRecordOverflow) 
-               return c.in.setErrorLocked(fmt.Errorf("tls: oversized record received with length %d", n)) 
+               return c.in.setErrorLocked(fmt.Errorf("tls: oversized record received with length %d ; data=%q", n, b.data)) 
        }
        if !c.haveVers {
                // First message, be extra suspicious: this might not be a TLS

Makes the demo program above error out with the "HTTP/1.1 400 Bad Request\r\nContent-Type: text/plain\r\nConnection: close\r\n\r\n400 Bad Request"

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

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

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