You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the cloudfoundry/gorouter we are silently retrying failed requests which are safe to retry, either because they are idempotent or never reached the upstream server.
This requires detailed understanding of the error that caused the request to fail. The crypto/tls package is currently rather secretive about its errors (in terms of comparability). All TLS alerts are mapped to go constants in crypto/tls/alert.go but not exported, therefore go applications cannot easily distinguish the error that occurred, neither between TLS and other errors, nor between different kinds of TLS errors.
There are probably more use-cases but this is the one that triggered discussions around this topic in our team.
Proposal
Export the alert type, export all defined alerts, wrap those alerts where appropriate.
This allows go code to easily check for the specific TLS error / alert and act accordingly:
To properly support unwrapping of errors all of these statements would need to be changed to something that wraps the alert properly (fmt.Errorf, custom error type, etc.). This could be considered an incompatible change since the error message would also change, I'm not sure if such a change is in line with the Go 1 Compatibility Promise, but I would guess yes.
The text was updated successfully, but these errors were encountered:
TL;DR: export everything in
crypto/tls/alert.go
(exceptalertText
?) and wrap the alerts where appropriate.Possibly related to: #48151 #51495
Issue
In the cloudfoundry/gorouter we are silently retrying failed requests which are safe to retry, either because they are idempotent or never reached the upstream server.
This requires detailed understanding of the error that caused the request to fail. The
crypto/tls
package is currently rather secretive about its errors (in terms of comparability). All TLS alerts are mapped to go constants incrypto/tls/alert.go
but not exported, therefore go applications cannot easily distinguish the error that occurred, neither between TLS and other errors, nor between different kinds of TLS errors.There are probably more use-cases but this is the one that triggered discussions around this topic in our team.
Proposal
Export the
alert
type, export all defined alerts, wrap those alerts where appropriate.This allows go code to easily check for the specific TLS error / alert and act accordingly:
The TLS Implementation distinguishes between two kinds of errors / alerts: those caused locally and those received from remote.
Remote Alerts
are covered by this piece of code, which ultimately wraps the alert and returns it:
Those can be checked easily once the alerts are exposed since they are already wrapped properly.
Local Alerts
are not at all returned. Most of the return statements currently look like this:
To properly support unwrapping of errors all of these statements would need to be changed to something that wraps the alert properly (
fmt.Errorf
, custom error type, etc.). This could be considered an incompatible change since the error message would also change, I'm not sure if such a change is in line with the Go 1 Compatibility Promise, but I would guess yes.The text was updated successfully, but these errors were encountered: