Comprende el código correctamente previamente a usarlo a tu trabajo y si tquieres aportar algo puedes decirlo en los comentarios.
Solución:
Una solicitud CONNECT insta a su proxy a establecer un túnel HTTP al punto final remoto.
Normalmente ¿Se usa para conexiones SSL, aunque también se puede usar con HTTP (se usa con fines de encadenamiento de proxy y tunelización)?
CONNECT www.google.com:443
La línea anterior abre una conexión desde su proxy a www.google.com en el puerto 443. Después de esto, el proxy reenvía el contenido que envía el cliente a www.google.com:443.
Si un usuario intenta recuperar una página http://www.google.com, el proxy puede enviar exactamente la misma solicitud y recuperar la respuesta para él, en su nombre.
Con SSL (HTTPS), solo los dos puntos finales remotos entienden las solicitudes y el proxy no puede descifrarlas. Por lo tanto, todo lo que hace es abrir ese túnel usando CONNECT y permite que los dos puntos finales (servidor web y cliente) se comuniquen entre sí directamente.
Encadenamiento de proxy:
Si está encadenando 2 servidores proxy, esta es la secuencia de solicitudes que se emitirán.
GET1 is the original GET request (HTTP URL)
CONNECT1 is the original CONNECT request (SSL/HTTPS URL or Another Proxy)
User Request ==CONNECT1==> (Your_Primary_Proxy ==CONNECT==> AnotherProxy-1 ... ==CONNECT==> AnotherProxy-n) ==GET1(IF is http)/CONNECT1(IF is https)==> Destination_URL
TL;RD un cliente web utiliza CONNECT solo cuando sabe que habla con un proxy y el URI final comienza con https://.
Cuando un navegador dice:
CONNECT www.google.com:443 HTTP/1.1
significa:
Hola proxy, abra una conexión TCP sin formato a google; cualquier siguiente byte que escriba, simplemente repite esa conexión sin ninguna interpretación. Ah, y una cosa más. Haz eso solo si hablas con Google directamente, pero si usas otro proxy tú mismo, simplemente diles lo mismo
CONNECT.
Tenga en cuenta que esto no dice nada sobre TLS (https). En realidad CONNECT es ortogonal a TLS; puedes tener solo uno, puedes tener otro, o puedes tener ambos.
Dicho esto, la intención de CONNECT es permitir sesión TLS cifrada de extremo a extremo, por lo que los datos son ilegibles para un proxy (o una cadena de proxy completa). Funciona incluso si un proxy no entiende TLS en absoluto, porque CONNECT se puede emitir dentro de HTTP simple y no requiere del proxy nada más que copiar bytes sin procesar.
Pero la conexión al primer proxy puede ser TLS (https) aunque supone una doble encriptación del tráfico entre tú y el primer proxy.
Obviamente, no tiene sentido CONNECT al hablar directamente con el servidor final. Simplemente comienza a hablar TLS y luego emite HTTP GET. Los servidores finales normalmente deshabilitan CONNECT en total.
a un apoderado, CONNECT el soporte agrega riesgos de seguridad. Cualquier dato puede ser pasado a través CONNECT, incluso intento de pirateo de ssh en un servidor en 192.168.1.*, incluso envío de spam por SMTP. El mundo exterior ve estos ataques como conexiones TCP regulares iniciadas por un proxy. No les importa cuál es el motivo, no pueden verificar si HTTP CONNECT tiene la culpa Por lo tanto, depende de los proxies protegerse contra el uso indebido.
Como regla general, GET se usa para HTTP simple y CONNECT para HTTPS.
Sin embargo, hay más detalles, por lo que probablemente desee leer los RFC-s relevantes
http://www.ietf.org/rfc/rfc2068.txt http://www.ietf.org/rfc/rfc2817.txt
Reseñas y valoraciones
Si posees algún titubeo y capacidad de acrecentar nuestro sección puedes ejecutar una nota y con deseo lo observaremos.