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

Ответ 1

Запрос CONNECT побуждает ваш прокси установить туннель 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

Ответ 2

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

Когда браузер говорит:

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. Следовательно это до прокси, чтобы обезопасить себя от неправильного использования.

Ответ 3

Как правило, GET используется для простых HTTP и CONNECT для HTTPS

Есть более подробная информация, поэтому вы, вероятно, захотите прочитать соответствующие RFC файлы

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