I Found Out Why an HTTP Header Check Took 16 Seconds and Fixed It

A user reported that entering pdns09.domaincontrol.com into the HTTP Header Tool caused the check to take about 16 seconds before returning:

HTTP request failed: This operation was aborted

The hostname was not returning an HTTP response, so timing out was reasonable. But making the user wait 16 seconds and then showing an internal error message was not. I traced the request through my tool and found two things to fix.

The HTTP Header Tool starts with a HEAD request. That asks a web server for its status and response headers without downloading the page body.

Some servers explicitly reject HEAD. If a server responds with405 Method Not Allowed or 501 Not Implemented, retrying with GET makes sense because the server is reachable and has told us that the request method is the problem.

My backend was also retrying with GET after any failedHEAD request, including a timeout:

HEAD request → wait 8 seconds → timeout
GET request  → wait 8 seconds → timeout
Total        → about 16 seconds

Changing the method cannot repair a DNS failure, connection problem, TLS failure, or server that is not returning an HTTP response. In those cases, the second request just repeats the failure.

My logic now retries with GET only when a server explicitly returns405 or 501. Transport failures no longer trigger that retry. For this lookup, the wait drops from about 16 seconds to about 8 seconds.

I also replaced the internal message:

This operation was aborted

with a result written for the person using the tool:

HTTP request timed out
No HTTP response was received within 8 seconds. The host may be unavailable or may not provide a web service.

Technical details are still available in an expandable section:

Requested URL:       https://pdns09.domaincontrol.com/
Method:              HEAD
Codynet error:       HTTP_UPSTREAM_TIMEOUT
Codynet API status:  504 Gateway Timeout
Destination status: No HTTP response received
Elapsed time:        8.0 seconds

The 504 is generated by the tool because its outbound request timed out. It does not mean the destination returned a 504; the destination did not return an HTTP response.

I tested the changed tool against several different destinations:

• A normal HTTPS site returned its headers successfully.
• An HTTP site redirected to HTTPS and completed normally.
• The originally reported hostname returned the new timeout after about 8 seconds.
• A site with an expired TLS certificate remained a separate connection error.

I also added automated coverage for successful HEAD requests,405 and 501 fallbacks, transport failures, timeout classification, and the new error display.

A retry should be based on evidence that it might succeed.

A 405 or 501 response gives us that evidence: the server is reachable, speaks HTTP, and rejected the method. A transport timeout does not. Automatically repeating it can make a tool feel slower while hiding the actual outcome.

The job is to show the protocol’s real answer clearly. When no answer arrives, the tool should say that plainly too.

This fix came from a real bug report about a result that did not feel right.

If Codynet returns something inaccurate, unclear, or unexpectedly slow, send the input and what you saw through the contact page. Reproducible reports help me improve the tools for everyone.