http://www.wiseuc.com/facontent.php?id=903
https://devcentral.f5.com/tech-tips/articles/tunneling-with-http-connect#.UTAqTjeKklg
http://www.web-cache.com/Writings/Internet-Drafts/draft-luotonen-web-proxy-tunneling-01.txt
There is no way to tell a browser that the server it is connecting to is actually a proxy. The browser only uses CONNECT when it knows about the proxy (typically, by local configuration).
When a browser creates a direct secure connection with an origin server, there are no HTTP CONNECT requests. The first HTTP request sent on such a connection is already encrypted.
A browser sends CONNECT requests when it is configured to talk to a proxy.
Background
To ensure that sensitive information is kept secret from potential
eavesdroppers, TCP/IP includes secure protocols (SSL/TLS) which have
been designed specifically to achieve true end-to-end security. These
protocols work by following a handshake algorithm to establish a shared
encryption key which is known only to the client and the secure server.
Once the handshake is complete, all subsequent data transfer between the
client and server are encrypted. Since the client and secure server are
the only devices which know the shared encryption key, they alone are
able to decrypt the communications using the shared encryption key.
A special case occurs when the client must use a proxy server to connect
to a remote secure server. The proxy server must connect the client to
the remote secure server so the handshake can take place to establish
the shared encryption key. To maintain true end-to-end security, this
encryption key must remain unknown to the proxy server .
To handle this special case, HTTP has a special method: CONNECT. This
method is used by a client to instruct a proxy server to establish a
connection with a remote server so that handshaking between the client
and the remote server can take place. At the end of the handshake, the
shared encryption key is established between the client and the remote
secure server. All subsequent communications between the client and the
remote secure server are encrypted using that key and sent to the proxy
server which then acts only as a data relay between the client and the
remote secure server. This is known as tunneling through the proxy.
Since the proxy server does not know the encryption key, it cannot
examine the data in the communications, and end-to-end security is
preserved.
=====
|
I'm building a WebClient library, now I'm implement a proxy feature, so making some research I saw some code use CONNECT method to request a URL. But sniff my web browser, it don't use CONNECT verb, it's call GET method instead. So I'm confuse, finaly, When I should use both methods? |
A CONNECT request urges your proxy to establish an HTTP tunnel to the remote end-point. Usually is it used for SSL connections, though it can be used with HTTP as well (used for the purposes of proxy-chaining and tunneling)
CONNECT www.google.com:443
The above line opens a connection from your proxy to www.google.com on port 443. After this, content that is sent by the client is forwarded by the proxy to www.google.com:443.
If a user tries to retrieve a page http://www.google.com, the proxy can send the exact same request and retrieve response for him, on his behalf.
With SSL(HTTPS), only the two remote end-points understand the requests, and the proxy cannot decipher them. Hence, all it does is open that tunnel using CONNECT, and lets the two end-points (webserver and client) talk to each other directly.
Proxy Chaining:
If you are chaining 2 proxy servers, this is the sequence of requests to be issued.
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
浙公网安备 33010602011771号