Я создаю библиотеку WebClient. Теперь я реализую прокси-функцию, поэтому я делаю некоторые исследования, и я видел некоторый код, используя метод CONNECT для запроса URL-адреса.
Но, проверяя его в моем веб-браузере, он не использует метод CONNECT, но вместо этого называет метод GET.
Так что я смущен. Когда я должен использовать оба метода?
Запрос 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
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. Следовательно это до прокси, чтобы обезопасить себя от неправильного использования.
Как правило, GET используется для простых HTTP и CONNECT для HTTPS
Есть более подробная информация, поэтому вы, вероятно, захотите прочитать соответствующие RFC файлы
http://www.ietf.org/rfc/rfc2068.txt http://www.ietf.org/rfc/rfc2817.txt