Quand faut-il utiliser les méthodes HTTP CONNECT et GET sur HTTP Proxy Server?
Je construis une bibliothèque WebClient. Maintenant, je suis en train d'implémenter une fonctionnalité de proxy, alors je fais des recherches et j'ai vu du code en utilisant la méthode CONNECT pour demander une URL.
Mais en le vérifiant dans mon navigateur Web, il n’utilise pas la méthode CONNECT mais appelle plutôt la méthode GET.
Donc je suis confus. Quand devrais-je utiliser les deux méthodes?
Une demande CONNECT demande à votre proxy d'établir un tunnel HTTP vers le point d'extrémité distant. Habituellement est-il utilisé pour les connexions SSL, bien qu'il puisse également être utilisé avec HTTP (utilisé à des fins de chaînage de proxy et de tunneling)
CONNECT www.google.com:443
La ligne ci-dessus ouvre une connexion de votre proxy à www.google.com sur le port 443. Ensuite, le contenu envoyé par le client est transféré par le proxy à www.google.com:443.
Si un utilisateur tente de récupérer une page http://www.google.com , le proxy peut envoyer exactement la même demande et récupérer une réponse pour lui, en son nom.
Avec SSL (HTTPS), seuls les deux points de terminaison distants comprennent les demandes et le proxy ne peut pas les déchiffrer. Par conséquent, il ne fait qu'ouvrir ce tunnel à l'aide de CONNECT et laisser les deux extrémités (serveur Web et client) se parler directement.
Chaînage de proxy:
Si vous chaînez 2 serveurs proxy, il s'agit de la séquence de demandes à émettre.
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; DR un client Web utilise CONNECT uniquement lorsqu'il sait qu'il communique avec un proxy et que l'URI final commence par https://.
Lorsqu'un navigateur dit:
CONNECT www.google.com:443 HTTP/1.1
ça veut dire:
"Bonjour proxy, veuillez ouvrir une connexion brute TCP à Google; les octets suivants que j’écris, il vous suffit de répéter cette connexion sans aucune interprétation. Oh, et encore une chose. Ne le faites que si vous parlez directement sur Google, mais si vous utilisez vous-même un autre proxy, vous leur indiquez simplement le même CONNECT. "
Notez que cela ne dit rien sur TLS (https). En fait, CONNECT est orthogonal à TLS; vous pouvez n'en avoir qu'un, vous pouvez en avoir d'autres ou les deux.
Cela étant dit, l'intention de CONNECT est d'autoriser session TLS cryptée de bout en bout, de sorte que les données sont illisibles pour un proxy (ou pour toute une chaîne de proxy). Cela fonctionne même si un proxy ne comprend pas du tout TLS, parce que CONNECT peut être émis à l'intérieur d'un simple HTTP et n'exige rien de plus du proxy que de copier des octets bruts.
Mais la connexion au premier proxy peut être TLS (https) bien que cela signifie un double cryptage du trafic entre vous et le premier proxy.
Évidemment, cela n’a aucun sens de CONNECT quand on parle directement au serveur final. Vous commencez juste à parler de TLS puis à émettre HTTP GET. Les serveurs finaux désactivent normalement CONNECT.
Pour un proxy, CONNECT support ajoute des risques de sécurité. Toutes les données peuvent être transmises via CONNECT, même une tentative de piratage SSH vers un serveur sous 192.168.1. *, Même par l'envoi de spam par SMTP. En dehors du monde, ces attaques sont perçues comme des connexions régulières TCP initiées par un proxy. Peu importe la raison, elles ne peuvent pas vérifier si HTTP CONNECT est à blâmer. aux mandataires de se protéger contre les abus.
Oui, je sais que je réponds à cela 4 ans plus tard, j'espère apporter de toute façon plus de clarté.
En règle générale, GET est utilisé pour HTTP simple et CONNECT pour HTTPS.
Il y a plus de détails, donc vous voulez probablement lire les RFC-s correspondantes
http://www.ietf.org/rfc/rfc2068.txthttp://www.ietf.org/rfc/rfc2817.txt