But if use the full interface, your LWP::UserAgent object has methods named send_request(), simple_request() and just request() which send off requests with various levels of preparation and munging first. But the important thing is that they can be anything that you want.

If only that were the case.

The syntax of CONNECT is: CONNECT host:port HTTP/1.0.

LWP overloads the URI field to contain both a) the host and port to connect to (to send the request to) and b) the URI to send in the request. I do HTTP::Request->new("CONNECT", "http://proxy1_host:proxy1_port/proxy2_host:proxy2_port", ...) and LWP sends CONNECT /proxy2_host:proxy2_port to proxy1_host:proxy1_port. So I hack LWP::Protocol::http to not send the slash.

Now comes the tunnelling. I'm supposed to be able to communicate through the tunnel once the connection is established and the tunnel sends HTTP/1.0 200 Connection established. I thought this would be as simple as sending an HTTP request in the content field:

$req = HTTP::Request->new("CONNECT", "http://proxy1_host:proxy1_port/p
+roxy2_host:proxy2_port",
HTTP::Headers->new(),
"GET http://final_destination.example.com/ HTTP/1.0\cJ\cM\cJ\cM");
[download]

Not so. The content comes before the response (which is expected, I guess):

CONNECT proxy2_host:proxy2_port HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: proxy2_host:proxy2_port
User-Agent: libwww-perl/5.68
Content-Length: 39

GET http://final_destination.example.com/ HTTP/1.0

HTTP/1.0 200 Connection established
[download]

So I can't get here from there, through LWP, as far as I can see.

HTTP::Lite suffers from the same disease.

request ( $url, $data_callback, $cbargs )
Initiates a request to the specified URL.

The host to connect to and the request to send are stuffed inside the $url parameter. I don't want to use URIs more than necessary, I just want to speak HTTP.

HTTP::MHTTP also crams the host to connect to and the request into a URI, passed to http_call.

Net::HTTPTunnel can do HTTP tunnelling through arbitrary TCP services. The only drawback is that I'll have to write my own HTTP, unless somehow one of these HTTP modules can be instructed to communicate on a given socket created by Net::HTTPTunnel. That's a reasonable trade-off, I suppose.

PS I have only seen multiple levels of proxying used by people who were attempting to use various open proxies to anonymize themselves.

RFC 2817 seems to disagree:

It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the first proxy SHOULD make a CONNECT request of that next proxy, requesting a tunnel to the authority.

I try to code for all relevant cases, and since I'm writing a program mainly for proxies this is relevant.

Its definitely possible that one will use an open proxy, but my program will also accept internal proxies; no distinction is made. Perhaps I could do a DNSRBL lookup, although such a check would slow down execution.

Having looked at the traffic that passed through one such proxy, the users paid attention to how much the server reported to others, and didn't seem to realize that the server they are proxying off of can keep logs including the information not passed on, and do things like hand it over to law enforcement... (Yes, I do know of at least one case where law enforcement took full advantage of this.)

Thanks for heads up -- I plan to take full advantage of this, also; but that's another thread.