A WHOIS Query Inside an HTTP CONNECT Tunnel

If a required lookup still uses traditional WHOIS, an HTTP proxy can carry that TCP exchange when its policy permits CONNECT to the WHOIS service. The client must finish the proxy handshake before sending the lookup text. For a permitted public WHOIS test with no proxy credentials configured, the HTTP proxy list offers candidate intermediaries; confirm separately that one allows the WHOIS service’s host and port 43.

For a hypothetical service named whois.example, begin with this HTTP request:

CONNECT whois.example:43 HTTP/1.1
Host: whois.example:43

Serialize HTTP line endings as CRLF. Read the complete proxy response, including its terminating empty header line, and check the numeric success status. Receiving part of the status line is not enough to start the next protocol.

Then send the WHOIS text

After the tunnel opens, send the query expected by that WHOIS server. A simple illustrative query is:

example.com<CRLF>

The marker represents carriage-return and line-feed bytes. It is not part of the domain name. There is no HTTP GET line or HTTP response status inside this WHOIS exchange.

Read the text until the WHOIS server closes the connection. A response can contain many lines; the first newline does not mean it is complete. Keep the connection and read waits bounded in the implementation.

This sequence also gives the parser two distinct boundaries. First comes an HTTP header block. After that comes the WHOIS response, whose completion is signalled by connection closure. Preserve any bytes buffered beyond a parsed boundary rather than discarding an entire network read.

A proxy rejection means the tunnel never opened, so sending a domain afterward cannot produce a WHOIS result. If the server’s answer points to another WHOIS service, any follow-up query needs its own permitted connection to that service.