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
{{ message }}
Repository navigation
HTTP/HTTPS check accepts non-2xx responses, leaks response body, and has no timeout #7
The HTTP check in https.go has three independent defects that, combined, make it unreliable as a connectivity validator:
Status code is never checked. The README states "An HTTP 2xx response is expected", but the code returns success on any non-error response — including 4xx and 5xx.
Response body is never closed. This leaks file descriptors and connections; in monitor mode it accumulates over time.
No timeout.http.Get uses the default client, which has no timeout. A slow or hung server will block the check indefinitely. In monitor mode that destination will simply stop being checked.
There is also a subtler design issue: the per-IP Dial loop validates connectivity to each address returned by DNS, but http.Get(dest.URL) re-resolves DNS internally via the OS resolver, so the actual HTTP request may end up at a different IP than what Lookup/Dial verified.
Code
https.go:
funcHTTPS(dest*Destination) bool {
dest.Increment("connectivity.http", []string{})
_, err:=http.Get(dest.URL) // no timeout; response discarded; body never closediferr!=nil {
dest.Increment("connectivity.http.error", []string{})
LogDestinationError(dest, "Failed HTTP GET", err)
returnfalse
}
dest.Increment("connectivity.http.success", []string{})
returntrue
}
Impact
A destination returning HTTP 500 is reported as "Connected", so the tool returns 0 from connectivity check and gates do not catch the failure.
Long-running monitor accumulates leaked connections and may hang on slow upstreams forever.
Activity
add hermetic tests for EscapeTag, statsd, LoadConfig, HTTPS, UrlString (