Com un sol port de proxy pot acceptar HTTP i SOCKS alhora
Explica com un oient deliberadament mixt pot distingir HTTP de SOCKS, mentre que un oient normal d'un sol protocol no ho pot fer.
Un oient de proxy mixt pot acceptar HTTP i SOCKS en un sol port TCP perquè el servidor inspecciona els bytes inicials del protocol. El número de port no fa aquesta detecció.
Una sol·licitud de proxy HTTP comença amb un mètode HTTP, com ara GET o CONNECT. Una salutació SOCKS comença amb camps binaris del protocol. El programari dissenyat per a aquestes entrades pot enviar la connexió al gestor adequat.
Aquesta és una característica explícita de la implementació. Un oient HTTP normal de Squid no esdevé mixt pel fet de canviar-ne el port a 1080, i un oient només SOCKS no aprèn HTTP a partir de la configuració del navegador.
TLS afegeix una altra frontera: una connexió de proxy xifrada comença amb TLS, no amb un mètode HTTP visible. Donar-hi suport al mateix punt final requereix un tractament addicional deliberat; reconèixer HTTP en text pla i SOCKS no estableix aquesta capacitat.
Feu servir el protocol de client documentat per al punt final. Si tots dos funcionen, això és una evidència sobre l'oient mixt d'aquell servidor, no un motiu per deixar el protocol sense especificar a tots els clients.
L'oient mixt de Glider ofereix un exemple concret: mira un byte sense consumir-lo, envia 0x05 al seu gestor SOCKS5 i, si no, invoca el seu analitzador HTTP. Aquest analitzador encara valida la sol·licitud entrant; l'elecció d'enviament no fa que una entrada arbitrària sigui HTTP vàlid.
Compartir l'oient TCP no proporciona per si mateix l'associació UDP de SOCKS5. Glider inicia el seu oient UDP per separat. La selecció del protocol TCP i el posterior relé de datagrames són capacitats separades.