Bug in datadog_checks/base/utils/http.py introducing a 10s timeout

[sebastien-prudhomme]

I've noticed a 10s timeout when using http_check on an URL with a problem in its certificate.

It seems related to that PR #14817

With an URL without a port, for instance "https://www.google.com", parsed_url.port is None and the code tries to connect to an empty port, leading to 10s default TCP timeout I guess.

[Kyle-Neale]

Hey @sebastien-prudhomme,

What's the configuration you're using to cause a timeout? I haven't been able to reproduce this issue:

2025-02-26 13:43:40 EST | CORE | INFO | (pkg/collector/worker/check_logger.go:59 in CheckFinished) | check:http_check | Done running check
2025-02-26 13:43:40 EST | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:150 in LogMessage) | http_check:google:7196443f2af3753e | (http_check.py:365) | seconds_left: 5234053.70285
2025-02-26 13:43:40 EST | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:150 in LogMessage) | http_check:google:7196443f2af3753e | (http_check.py:364) | Exp_date: 2025-04-28 08:37:54
2025-02-26 13:43:40 EST | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:150 in LogMessage) | http_check:google:7196443f2af3753e | (http_check.py:94) | https://www.google.com is UP
2025-02-26 13:43:40 EST | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:150 in LogMessage) | - | (connectionpool.py:546) | https://www.google.com:443 "GET / HTTP/11" 200 None
2025-02-26 13:43:40 EST | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:150 in LogMessage) | - | (connectionpool.py:1051) | Starting new HTTPS connection (1): www.google.com:443
2025-02-26 13:43:40 EST | CORE | DEBUG | (pkg/collector/python/datadog_agent.go:150 in LogMessage) | http_check:google:7196443f2af3753e | (http_check.py:114) | Connecting to https://www.google.com

This is my configuration:

- name: google
  url: https://www.google.com

I didn't mean to close - reopening issue.

[sebastien-prudhomme]

Hi @Kyle-Neale , the problem happens when using a website with a problem in it's certificate. Our certificate had only a CommonName and no subjectAltName which is now considered as a bad certificate in Python or Chrome.

"https://www.google.com/" is just an example for the parsing problem. Maybe you can reproduce by using one of the URL on https://badssl.com/ like https://wrong.host.badssl.com/