Когда следует использовать методы CONNECT и GET HTTP на прокси-сервере HTTP?

Я создаю библиотеку WebClient. Теперь я реализую функцию прокси, поэтому я делаю некоторые исследования, и я видел некоторый код, используя CONNECT метод запроса URL-адреса.

но проверяя его в моем веб-браузере, он не использует CONNECT метод, но вместо этого вызывает метод GET.

поэтому я в замешательстве. Когда я должен использовать оба метода?

37
http-proxy http-request httpwebrequest proxy proxy-server

3 ответов

запрос на подключение побуждает ваш прокси-сервер установить HTTP-туннель к удаленной конечной точке. обычно используется ли он для SSL-соединений, хотя он также может использоваться с HTTP (используется для прокси-цепочки и туннелирования)

CONNECT www.google.com:443

вышеуказанная строка открывает соединение с вашим прокси-сервером www.google.com по порту 443. После этого содержимое, отправленное клиентом, пересылается прокси-сервером в www.google.com:443.

если пользователь пытается загрузить страницу http://www.google.com, прокси может отправить тот же самый запрос и получить ответ для него от его имени.

С SSL (HTTPS) только две удаленные конечные точки понимают запросы, и прокси-сервер не может их расшифровать. Следовательно, все, что он делает, это открывает этот туннель с помощью CONNECT и позволяет двум конечным точкам (веб-серверу и клиенту) напрямую разговаривать друг с другом.

Прокси-Цепочки:

Если вы связываете 2 прокси-сервера, это последовательность запросов.

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
56

TL; DR веб-клиент использует CONNECT только тогда, когда он знает, что он разговаривает с прокси-сервером, и окончательный URI начинается с https://.

Да я отвечаю после 4 лет. Когда браузер говорит:

CONNECT www.google.com:443 HTTP/1.1

это значит:

"Привет прокси, пожалуйста, откройте необработанное TCP-соединение с google; любые следующие байты, которые я пишу, вы просто повторяете это соединение без какой-либо интерпретации. И еще кое-что. Сделайте это только если поговорите с google напрямую, но если вы используете другой прокси себя, вместо этого вы просто сказать им то же самое CONNECT."

обратите внимание, что это ничего не говорит о TLS (https). На самом деле CONNECT ортогонально TLS; вы можете иметь только один, вы можете иметь другой, или вы можете иметь оба из них.

тем не менее, намерение CONNECT - разрешить сквозной зашифрованный сеанс TLS, поэтому данные нечитаемы для прокси (или целой цепочки прокси). Он работает, даже если прокси-сервер вообще не понимает TLS, потому что CONNECT может быть выдан внутри обычного HTTP и не требует от прокси ничего больше, чем копирование необработанных байтов вокруг.

но подключение к первому прокси может быть TLS (https), хотя это означает двойное шифрование трафика между вами и первым прокси.

очевидно, это не имеет смысла CONNECT при разговоре непосредственно с конечным сервером. Вы просто начинаете говорить TLS, а затем выдаете HTTP GET. Конечные серверы обычно отключают CONNECT в целом.

по доверенности, CONNECT поддержка добавляет риски для безопасности. Любые данные могут быть переданы через CONNECT, даже ssh попытка взлома сервера на 192.168.1.* , даже SMTP отправка спама. Внешний мир рассматривает эти атаки как регулярные TCP-соединения, инициированные прокси-сервером. Им все равно, в чем причина, они не могут проверить, HTTP CONNECT виноват. Следовательно, это до прокси, чтобы защитить себя от неправильного использования.

29

Как правило, GET используется для простого HTTP и подключения для HTTPS

есть больше деталей, хотя, вероятно, вы хотите прочитать соответствующий RFC-s

http://www.ietf.org/rfc/rfc2068.txt http://www.ietf.org/rfc/rfc2817.txt

15