En WHOIS-fråga inuti en HTTP CONNECT-tunnel
Följ proxy-handskakningen och WHOIS-begäran som två separata utbyten när en tillåten HTTP CONNECT-rutt bär en TCP-fråga till port 43.
Om en nödvändig sökning fortfarande använder traditionell WHOIS kan en HTTP-proxy bära det TCP-utbytet när dess policy tillåter CONNECT till WHOIS-tjänsten. Klienten måste slutföra proxy-handskakningen innan den skickar söktexten. För ett tillåtet offentligt WHOIS-test utan konfigurerade proxyuppgifter erbjuder HTTP-proxylistan möjliga mellanhänder; bekräfta separat att en av dem tillåter WHOIS-tjänstens värd och port 43.
För en hypotetisk tjänst som heter whois.example, börja med denna HTTP-begäran:
CONNECT whois.example:43 HTTP/1.1
Host: whois.example:43
Skriv HTTP-radslut som CRLF. Läs hela proxy-svaret, inklusive dess avslutande tomma rubrikrad, och kontrollera den numeriska statusen för lyckat resultat. Att ta emot en del av statusraden räcker inte för att starta nästa protokoll.
Skicka sedan WHOIS-texten
När tunneln är öppen, skicka den fråga som den WHOIS-servern förväntar sig. En enkel illustrativ fråga är:
example.com<CRLF>Markören representerar byte för vagnretur och radmatning. Den är inte en del av domännamnet. Inuti detta WHOIS-utbyte finns ingen HTTP GET-rad och ingen HTTP-svarsstatus.
Läs texten tills WHOIS-servern stänger anslutningen. Ett svar kan innehålla många rader; den första nya raden betyder inte att det är komplett. Håll tidsgränserna för anslutning och läsning begränsade i implementeringen.
Denna sekvens ger också parsern två olika gränser. Först kommer ett HTTP-rubrikblock. Därefter kommer WHOIS-svaret, vars slutförande signaleras av att anslutningen stängs. Bevara alla byte som buffrats bortom en tolkad gräns i stället för att kasta en hel nätverksläsning.
Ett avslag från proxyn innebär att tunneln aldrig öppnades, så att skicka en domän efteråt kan inte ge ett WHOIS-resultat. Om serverns svar pekar på en annan WHOIS-tjänst behöver varje uppföljningsfråga sin egen tillåtna anslutning till den tjänsten.