Support PROXY_TYPE_HTTP_NO_TUNNEL

[fmoo]

httplib2 took a patch to add a new proxy type, HTTP_NO_TUNNEL in https://code.google.com/p/httplib2/issues/detail?id=38. Basically this allows you to specify that you want to use an HTTP proxy, but you do not want to use the CONNECT method for connecting to https://

[fmoo]

I might have the bandwidth to work on this in a week or two, but just filing this to track in the meantime.

[mikedougherty]

So there's a port of the patch from httplib2, but I haven't tested it yet so it's still sitting in a branch. I'm not sure if you had more in mind than this.

Though I have take no issue with supporting this use case, I'm having trouble understanding it. I've always taken this module (socks.py) is to be a replacement for 'socket' (more specifically TCP sockets), i.e. transport layer. Using HTTP(S) with CONNECT enables the use of connect, send, recv, close, getpeername and so on, and any TCP application can use it as a substitute for a 'vanilla' socket. Using HTTP's proxy support over HTTP is purely application-layer and I think should be the responsibility of whatever's using the socket (*see below). Unless there's something I'm unaware of, with HTTP_NO_TUNNEL a socks.socksocket would only be capable of making single HTTP request in the very naive fashion of sck.connect(server); sck.sendall(http_req); response = sck.recv(HUGE_BUFSIZE); sck.close().

* For example, urllib2 and the python3 equivalent offer ProxyHandler and ProxyBasicAuthHandler to perform this task. After some simple googling, it seems like httplib2 does not offer this, which I honestly find surprising. Oh well ;)

[mikedougherty]

Closing this in the interest of #4 - let's direct development towards PySocks.

(...also there's been no activity here for months)

[Anorov]

Though this is dead, this is actually something I considered quite a bit while upgrading PySocks.

In short: if one looks at how HTTP proxying works, both in the cases of CONNECT tunnels and regular HTTP proxies, it is much more sensible to implement this at the HTTP client layer, and not a separate proxying library. SOCKS proxies and HTTP proxies are very different in nature.

So, basically exactly what @mikedougherty said.

In PySocks, I decided not to implement regular HTTP proxying, though I did keep the original CONNECT tunnelling method. I added copious amounts of comments and helpful exception messages to indicate that it only supports CONNECT-style proxying, and not traditional HTTP proxying. I would highly advise relying on your HTTP client's proxying features, and to avoid all SocksiPy/PySocks HTTP-related code entirely.

The urllib3 library (which is similar in scope to httplib2, but in combination with the requests library is in my opinion a better and cleaner result) currently has full support for regular HTTP proxying, and CONNECT proxying for https. So it should be just fine.