Hvordan én proxy-port kan acceptere både HTTP og SOCKS
Forklarer hvordan en bevidst blandet lytter kan skelne HTTP og SOCKS, mens en normal enkeltprotokol-lytter ikke kan.
En blandet proxy-lytter kan acceptere HTTP og SOCKS på én TCP-port, fordi serveren inspicerer de indledende protokolbytes. Portnummeret udfører ikke den registrering.
En HTTP-proxyanmodning begynder med en HTTP-metode, f.eks. GET eller CONNECT. En SOCKS-hilsen begynder med binære protokolfelter. Software designet til disse input kan sende forbindelsen videre til den relevante handler.
Dette er en eksplicit implementeringsfunktion. En normal Squid HTTP-lytter bliver ikke blandet, fordi dens port ændres til 1080, og en lytter, der kun taler SOCKS, lærer ikke HTTP fra en browsers indstilling.
TLS tilføjer en anden grænse: en krypteret proxyforbindelse begynder med TLS, ikke med en synlig HTTP-metode. Understøttelse af det på samme endepunkt kræver yderligere bevidst håndtering; at genkende klartekst-HTTP og SOCKS fastslår ikke den evne.
Brug den klientprotokol, der er dokumenteret for endepunktet. Hvis begge virker, er det et bevis på den pågældende servers blandede lytter, ikke en grund til at lade protokollen være uspecificeret i hver klient.
Gliders blandede lytter giver et konkret eksempel: den kigger på én byte uden at forbruge den, sender 0x05 til sin SOCKS5-handler og kalder ellers sin HTTP-parser. Den parser validerer stadig den indgående anmodning; valget af afsendelse gør ikke vilkårligt input til gyldig HTTP.
Deling af TCP-lytteren giver ikke i sig selv SOCKS5 UDP-association. Glider starter sin UDP-lytter separat. Valg af TCP-protokol og den senere datagram-videresendelse er separate evner.