ProxHTTPSProxyMII: Development

[soccerfan]

(Jan. 15, 2015 01:47 AM)whenever Wrote:  ...Here comes the version 1.3 of ProxHTTPSProxyMII: ...

Any chance of an exe version

[JJoe]

Version 1.3 does not work for me with urllib3 1.10.1.
It does work with urllib3 1.9.1.

[whenever]

I have 1.10.2, which had been on pypi for several days but was rolled back to 1.10.1 later for reasons unknown.

It seems the urllib3 team is refactoring the code on http headers handling, and that breaks somethings. I prefer to waiting until they finish the refactoring.

Attached is a quick fix that works with 1.10.2. I'm not sure if it works with 1.10.1.

[GunGunGun]

Can we now use sock proxy with ProxHTTPSProxy ?
[PROXY socks://127.0.0.1:1080]
*

I found this github: https://github.com/Anorov/PySocks

And I doubt is there a way to integrate web server feature into ProxHTTPSProxy, I want to use ProxHTTPSProxy to host local folder of userscripts because ProxHTTPSProxy can bypass self-signed warning every time I restart Chrome/IE, I don't know why other webserver software support https web server have to do that again and again. I just want to do that for my personal use only.

[JJoe]

(Apr. 18, 2015 03:44 AM)GunGunGun Wrote:  Can we now use sock proxy with ProxHTTPSProxy ?
[PROXY socks://127.0.0.1:1080]
*

I found this github: https://github.com/Anorov/PySocks

Not yet. I think there is more work to be done.

github.com/Anorov/PySocks Wrote:urllib3, which powers the requests module, is working on integrating SOCKS proxy support based on this branch

[GunGunGun]

Oh, what a pain, the author of PySocks is busying with his school, I want this feature so badly. Thanks.

[whenever]

A minor update:

Code:

Version 1.3.1 (20151001)
--------------

* Certifications are now signed via SHA256 instead of SHA1

Should work with the latest urllib3 v1.12.

[Faxopita]

Hello Whenever,

thank you for the update. Could you please post the Python version as well? I can't run Windows executable on my platform… I'm on a Mac.

[whenever]

@Faxopita, all releases I posted in this thread are python versions.

[kik0s]

@whenever thanks a lot for the great work. is there any way to run th .py process in the background?! i am running it on a debian distro through a shell. so i have to leave it on all the time. thats a lil annoying. and what is this error all about:

Code:

"EOF occurred in violation of protocol (_ssl.c:600)" while trying to establish local SSL tunnel for [secure.somesite.com:443]

[whenever]

@kik0s, you can use something like Supervisor to put it into background.

About the SSL error, I guess it is compatibility issue. If the site fails to work, you can put it into the [SSL Pass-Thru] section of the config file.

[Greyhat Harry]

First of all, thank you so much for this excellent piece of software. It's vastly extended the useful life of good ole' Proxomitron, for which there's no true modern replacement.

But I'm having a little issue here. ProxHTTPSProxyMII doesn't seem to be honoring the "connection:close" header when using HTTPS.

This works fine for standard HTTP 1.1, but not for encrypted connections. I also tried not sending a connection header at all (which usually has the same effect as connection:close), going as far as forcing "Send only HTTP/1.0 requests" and "Local connections persist for..." from Proxomitron itself, both of which actually work ok with the now obsolete SSleay/openSSL option (not that I'm using it, but I make mention thereof for the very argument's sake), yet it all seems to be completely ignored by ProxHTTPSProxyMII, thus whatever connection's established, it will not be closed with enough immediacy and actually be handled as keep-alive (I can understand why this is a desirable default behavior under regular, everyday circumstances, but to me it is a necessity to go the other way around, even as potentially wasteful as non-persistent HTTPS connections may be, though they're perfectly valid)

In short, it is my request, if you should hearken unto it, that "HTTPS 1.0 connections" or so to speak, be made viable, so that both sending no connection header and sending a close connection header, will operate exactly as they would for standard HTTP connections.

Best regards and sorry for the inconveniences.

[whenever]

@Greyhat Harry, could you please refer to http://www.proxfilter.net/proxhttpsproxy/HowItWorks.gif and advise which connections you are talking about?

[Greyhat Harry]

Well, the connection:close header shows up correctly in Proxomitron's log for the initial GET requests, meaning the issue may not be with the front server but rather with the rear server, which appears to be forcing keep-alive regardless.

[whenever]

"Connection" is one of those hop-by-hop headers that shouldn't pass through a Proxy, so it is removed by both the front and rear servers. However, if "Connection:close" is detected, the connection will be closed anyway.