genotrance / px Goto Github PK

Looking into the issue it appears px.py failes to compile under python 2.7. The documentation didn't state which version of python was needed to build the application.

Hi genotrance,

Firstly thanks for building this awesome tool.

At my corp offices it seems by default Kerberos authentication is used and NTLM does not work for authenticating through the corporate proxy, is there any possibility you could work at adding authentication via using a Kerberos ticket cache?

I am happy to contribute if you can give me some guidance as to what needs to be done - I am familiar with Python but have no idea how these authentication mechanisms work.

While testing against squid 3.5.27 (latest stable) I observed the following behaviour:
A client using HTTP/1.0 w/o a Proxy-Connection: Keepalive header cannot be authenticated with NTLM; a HTTP/1.0 with Proxy-Connection: Keepalive header is authenticated as well as a HTTP/1.1 client regardless of the header.

As far as my research indicates, this is a valid behaviour: HTTP/1.1 implies a connection keep alive and NTLM auth may require connection keep alive (esp. in order to keep challenge and response together if going through a load balancer).

A possible solution would be to add an option for px to send a Proxy-Connection: keepalive header regardless of client's request (or at least for HTTP/1.0 connections).

Here are the test cases (latest stable curl 7.55.1):

# HTTP/1.0 w/ Proxy-Connection Header // working
curl --proxy 127.0.0.1:3128  -v -0 http://some.server.de 
# HTTP/1.1 w/o Proxy-Connection Header // working
curl --proxy 127.0.0.1:3128 --proxy-header Proxy-Connection: -v  http://some.server.de
# HTTP/1.0 w/o Proxy-Connection Header // failing
curl --proxy 127.0.0.1:3128 --proxy-header Proxy-Connection: -v -0 http://some.server.de

Hello,

I would like to request the same feature as the one described in the cntlm.ini file of CNTLM :

Tunnels mapping local port to a machine behind the proxy.
The format is <local_port>:<remote_host>:<remote_port>
Tunnel 7777:machine.foobar.net:443

I'm heavily using this feature and it would be great to have it on px.

Any advice on that matter would be much appreciated.

Cheers.

I've just tried to use your pac file imlementation the first time, but got an Error 87 (ERROR_INVALID_PARAMETER) from WinHttpOpen (maybe related to #49 ). After some reading in the documentation, I saw that WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY is only supported on Win 8.1 and newer, but I'm using Win 7 and that's why I need WINHTTP_ACCESS_TYPE_DEFAULT_PROXY.

Also the proxies inside the pac file could also be devided by a ;, that's why I added a second replace.

--- px.py       2018-05-17 14:42:04.655400100 +0200
+++ px.py       2018-05-17 14:44:08.161400100 +0200
@@ -169,6 +169,13 @@
     Prevents logs from being overwritten on subsequent runs. Also useful if
     running multiple instances of Px""" % __version__
 
+# Windows Version
+#  6.1 = Windows 7
+#  6.2 = Windows 8
+#  6.3 = Windows 8.1
+# 10.0 = Windows 10
+WIN_VERSION = float(str(sys.getwindowsversion().major) + '.' + str(sys.getwindowsversion().minor))
+    
 # Proxy modes - source of proxy info
 MODE_NONE = 0
 MODE_CONFIG = 1
@@ -917,14 +924,20 @@
 WINHTTP_AUTO_DETECT_TYPE_DNS_A = 0x00000002
 
 # dwAccessType values
+WINHTTP_ACCESS_TYPE_DEFAULT_PROXY = 0
 WINHTTP_ACCESS_TYPE_NO_PROXY = 1
 WINHTTP_ACCESS_TYPE_NAMED_PROXY = 3
 WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY = 4
 
 def winhttp_find_proxy_for_url(url, autodetect=False, pac_url=None, autologon=True):
+    if WIN_VERSION >= 6.3:
+        ACCESS_TYPE = WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY
+    else:
+        ACCESS_TYPE = WINHTTP_ACCESS_TYPE_DEFAULT_PROXY
+    
     hInternet = ctypes.windll.winhttp.WinHttpOpen(
         ctypes.wintypes.LPCWSTR("Px"),
-        WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY, WINHTTP_NO_PROXY_NAME,
+        ACCESS_TYPE, WINHTTP_NO_PROXY_NAME,
         WINHTTP_NO_PROXY_BYPASS, WINHTTP_FLAG_ASYNC)
     if not hInternet:
         dprint("WinHttpOpen failed: " + str(ctypes.GetLastError()))
@@ -957,7 +970,7 @@
         if not proxy_info.lpszProxy:
             dprint('WinHttpGetProxyForUrl named proxy without name')
             return ""
-        return proxy_info.lpszProxy.replace(' ', ',') # Note: We only see the first!
+        return proxy_info.lpszProxy.replace(' ', ',').replace(';', ',') # Note: We only see the first!
     if proxy_info.dwAccessType == WINHTTP_ACCESS_TYPE_NO_PROXY:
         return "DIRECT"

Is there any reason why you are capturing the error response and sending back an error from SimpleHttp? This has been causing some issues in certain programs that are expecting a specific error to come back from a service. Would it be possible to make this a toggleable configuration?

I have a rather strange issue currently.

If I'm using a compiled px.exe (with or without shim, latest version) no useful logs are generated any more. Some initial lines are in the console, but nothing about request, socket and proxy authentication stuff.

The generated log files debug-MainProcess.log and debug-Process-1.log stay at 0 Bytes, no matter what I do.

This is my log in the shell:

px.exe --proxy=proxy.rwe.com:8080 --hostonly --debug

MainProcess: MainThread: 1520585210: parse_proxy: [('proxy.rwe.com', 8080)]
MainProcess: MainThread: 1520585210: parse_proxy: [('proxy.rwe.com', 8080)]
MainProcess: MainThread: 1520585210: parse_config: Turning allow off
Serving at :3128 proc MainProcess
MainProcess: MainThread: 1520585210: parse_config: proxy:server = proxy.rwe.com:8080
MainProcess: MainThread: 1520585210: parse_config: proxy:listen =
MainProcess: MainThread: 1520585210: parse_config: proxy:port = 3128
MainProcess: MainThread: 1520585210: parse_config: proxy:gateway = 0
MainProcess: MainThread: 1520585210: parse_config: proxy:hostonly = 1
MainProcess: MainThread: 1520585210: parse_config: proxy:allow =
MainProcess: MainThread: 1520585210: parse_config: proxy:noproxy =
MainProcess: MainThread: 1520585210: parse_config: proxy:useragent =
MainProcess: MainThread: 1520585210: parse_config: settings:workers = 2
MainProcess: MainThread: 1520585210: parse_config: settings:threads = 5
MainProcess: MainThread: 1520585210: parse_config: settings:idle = 30
MainProcess: MainThread: 1520585210: parse_config: settings:socktimeout = 5.0
MainProcess: MainThread: 1520585210: parse_config: settings:proxyreload = 60
MainProcess: MainThread: 1520585210: parse_config: settings:foreground = 0
MainProcess: MainThread: 1520585210: parse_config: settings:log = 0
Process-1: MainThread: 1520585211: parse_proxy: [('proxy.rwe.com', 8080)]
Process-1: MainThread: 1520585211: parse_proxy: [('proxy.rwe.com', 8080)]
Process-1: MainThread: 1520585211: parse_config: Turning allow off
Serving at :3128 proc Process-1
Process-1: MainThread: 1520585211: parse_config: proxy:server = proxy.rwe.com:8080
Process-1: MainThread: 1520585211: parse_config: proxy:listen =
Process-1: MainThread: 1520585211: parse_config: proxy:port = 3128
Process-1: MainThread: 1520585211: parse_config: proxy:gateway = 0
Process-1: MainThread: 1520585211: parse_config: proxy:hostonly = 1
Process-1: MainThread: 1520585211: parse_config: proxy:allow =
Process-1: MainThread: 1520585211: parse_config: proxy:noproxy =
Process-1: MainThread: 1520585211: parse_config: proxy:useragent =
Process-1: MainThread: 1520585211: parse_config: settings:workers = 2
Process-1: MainThread: 1520585211: parse_config: settings:threads = 5
Process-1: MainThread: 1520585211: parse_config: settings:idle = 30
Process-1: MainThread: 1520585211: parse_config: settings:socktimeout = 5.0
Process-1: MainThread: 1520585211: parse_config: settings:proxyreload = 60
Process-1: MainThread: 1520585211: parse_config: settings:foreground = 0
Process-1: MainThread: 1520585211: parse_config: settings:log = 0

px seems to work fine as a proxy.

I've seen the commit 4a07056, but I've no idea what could cause this behaviour.

Hello, I opened the px.ini in notepad++ with admin rights and entered my server info. When I try to run px.exe, i am getting Failed to execute script px. My co-worker, however was able to complete the same steps with no issue.

Are there any troubleshooting steps I can take?

Thank you,
Teresa

I have installed netaddr 0.7.19 per directions, but whenever I try to run px.py, I get the message "Requires modules netaddr". I am running python 27 on Windows 7.

Hi,

In order to be able to ease the use in a work environnement, providing an installer that can install a windows service directly would be really useful.

Ton of thanks for Px :)

It seems that px, cntlm and ntlmaps don't work when the requested URL is HTTPS and has a certificate.
If in IntelliJ IDEA I set the proxy to the one of px and want to update IntelliJ then IntelliJ displays a window with the details of the certificate which I can then accept. But other tools for which I used px don't display any window with the certificate but an error message, like ConEmu. There should be a solution for this in px. The easiest would be an option to trust all certificates. I am no expert, I hope you understand what the problem is and can provide a solution.

Hi,

I think the latest pre-release is no longer able to authenticate against our proxy.

This is the current log:

Process-1: MainThread: 1519632465: verify_request: Client address: 127.0.0.1
Process-1: Thread_0: 1519632465: do_CONNECT: Entering
Process-1: Thread_0: 1519632465: do_transaction: Entering
Process-1: Thread_0: 1519632465: get_response: winkerberos SSPI
Process-1: Thread_0: 1519632465: do_socket: Entering
Process-1: Thread_0: 1519632465: do_socket_connect: New connection: ('proxy.rwe.com', 8080)
Process-1: Thread_0: 1519632465: do_socket: b'CONNECT github.com:443 HTTP/1.1\r\n'
Process-1: Thread_0: 1519632465: do_socket: Sending b'Host: github.com:443\r\n'
Process-1: Thread_0: 1519632465: do_socket: Sending b'User-Agent: git/2.15.0.windows.1\r\n'
Process-1: Thread_0: 1519632465: do_socket: Sending b'Proxy-Connection: Keep-Alive\r\n'
Process-1: Thread_0: 1519632465: do_socket: Sending extra b'Proxy-Authorization: Negotiate YIGeBgYrBgEFBQKggZM... and much more... olAmCpGQrZA=\r\n'
Process-1: Thread_0: 1519632465: do_socket: Reading response code
Process-1: Thread_0: 1519632466: do_socket: Response code: 407 False
Process-1: Thread_0: 1519632466: do_socket: Reading response headers
Process-1: Thread_0: 1519632466: do_socket: Received header Proxy-Authenticate = NEGOTIATE oRUwE6AD... and much more... BgjcCAgo=
Process-1: Thread_0: 1519632466: do_socket: Received header Cache-Control = no-cache
Process-1: Thread_0: 1519632466: do_socket: Received header Pragma = no-cache
Process-1: Thread_0: 1519632466: do_socket: Received header Content-Type = text/html; charset=utf-8
Process-1: Thread_0: 1519632466: do_socket: Received header Proxy-Connection = Keep-Alive
Process-1: Thread_0: 1519632466: do_socket: Received header Connection = Keep-Alive
Process-1: Thread_0: 1519632466: do_socket: Received header Content-Length = 2549
Process-1: Thread_0: 1519632466: do_socket: Reading response data
Process-1: Thread_0: 1519632466: do_socket: Content length 2549
Process-1: Thread_0: 1519632466: do_transaction: Auth required
Process-1: Thread_0: 1519632466: do_transaction: Didn't get challenge, not NTLM proxy
Process-1: Thread_0: 1519632466: do_CONNECT: Error 407
Process-1: Thread_0: 1519632466: log_message: code 407, message Proxy Authentication Required
Process-1: Thread_0: 1519632466: log_message: "CONNECT github.com:443 HTTP/1.1" 407 -
Process-1: Thread_0: 1519632466: do_CONNECT: Transferred 0 bytes
Process-1: Thread_0: 1519632466: do_CONNECT: Done

And this is from an older 0.2 release:

Process-1: MainThread: 1519632294: verify_request: Client address: 127.0.0.1
Process-1: Thread_0: 1519632294: do_CONNECT: Entering
Process-1: Thread_0: 1519632294: do_transaction: Entering
Process-1: Thread_0: 1519632294: get_response_wkb: winkerberos SSPI
Process-1: Thread_0: 1519632294: do_socket: Entering
Process-1: Thread_0: 1519632294: do_socket: New connection
Process-1: Thread_0: 1519632294: do_socket: b'CONNECT github.com:443 HTTP/1.1\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending b'Host: github.com:443\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending b'User-Agent: git/2.15.0.windows.1\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending b'Proxy-Connection: Keep-Alive\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending extra b'Proxy-Authorization: NTLM TlRMTVNTUAABAAAAl7II4gUA... and much more... BMDY1M0dST1VQ\r\n'
Process-1: Thread_0: 1519632294: do_socket: Reading response code
Process-1: Thread_0: 1519632294: do_socket: Response code: 407 False
Process-1: Thread_0: 1519632294: do_socket: Reading response headers
Process-1: Thread_0: 1519632294: do_socket: Received header Proxy-Authenticate = NTLM TlRMTVNTUAACAAAACgAKADgAAAAV... and much more... ABwAIAPmST3zYrtMBAAAAAA==
Process-1: Thread_0: 1519632294: do_socket: Received header Cache-Control = no-cache
Process-1: Thread_0: 1519632294: do_socket: Received header Pragma = no-cache
Process-1: Thread_0: 1519632294: do_socket: Received header Content-Type = text/html; charset=utf-8
Process-1: Thread_0: 1519632294: do_socket: Received header Proxy-Connection = Keep-Alive
Process-1: Thread_0: 1519632294: do_socket: Received header Connection = Keep-Alive
Process-1: Thread_0: 1519632294: do_socket: Received header Content-Length = 2549
Process-1: Thread_0: 1519632294: do_socket: Reading response data (nobody: False)
Process-1: Thread_0: 1519632294: do_socket: Content length 2549
Process-1: Thread_0: 1519632294: do_transaction: Auth required
Process-1: Thread_0: 1519632294: do_transaction: Challenged
Process-1: Thread_0: 1519632294: get_response_wkb: winkerberos SSPI
Process-1: Thread_0: 1519632294: do_socket: Entering
Process-1: Thread_0: 1519632294: do_socket: b'CONNECT github.com:443 HTTP/1.1\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending b'Host: github.com:443\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending b'User-Agent: git/2.15.0.windows.1\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending b'Proxy-Connection: Keep-Alive\r\n'
Process-1: Thread_0: 1519632294: do_socket: Sending extra b'Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAIIAAA... and much more... J2HBxQa\r\n'
Process-1: Thread_0: 1519632294: do_socket: Reading response code
Process-1: Thread_0: 1519632294: do_socket: Response code: 200 True
Process-1: Thread_0: 1519632294: do_socket: Reading response headers
Process-1: Thread_0: 1519632294: do_socket: Reading response data (nobody: True)
Process-1: Thread_0: 1519632294: do_CONNECT: Tunneling through proxy
127.0.0.1 - - [26/Feb/2018 09:04:54] "CONNECT github.com:443 HTTP/1.1" 200 -
Process-1: Thread_0: 1519632295: do_CONNECT: Transferred 6094 bytes
Process-1: Thread_0: 1519632295: do_CONNECT: Done

Any idea!? This might be related to #22.

I'm having issues with large files

Process-1: Thread_1: 1524733960: do_socket: Reading response headers
Process-1: Thread_1: 1524733960: do_socket: Received Server: Apache
Process-1: Thread_1: 1524733960: do_socket: Received Accept-Ranges: bytes
Process-1: Thread_1: 1524733960: do_socket: Received Content-Type: application/zip
Process-1: Thread_1: 1524733960: do_socket: Received Last-Modified: Fri, 26 Jan 2018 07:39:56 GMT
Process-1: Thread_1: 1524733960: do_socket: Received Content-Length: 3814407425
Process-1: Thread_1: 1524733960: do_socket: Received Date: Thu, 26 Apr 2018 09:12:40 GMT
Process-1: Thread_1: 1524733960: do_socket: Received Connection: close
Process-1: Thread_1: 1524733961: do_socket: Received Age: 0
Process-1: Thread_1: 1524733961: do_socket: Reading response data
Process-1: Thread_1: 1524733961: do_socket: Content length 3814407425

Exception happened during processing of request from ('10.0.0.3', 52351)
Traceback (most recent call last):
File "socketserver.py", line 639, in process_request_thread
File "socketserver.py", line 361, in finish_request
File "socketserver.py", line 696, in init
File "http\server.py", line 418, in handle
File "px.py", line 288, in handle_one_request
File "http\server.py", line 406, in handle_one_request
File "px.py", line 635, in do_GET
File "px.py", line 584, in do_transaction
File "px.py", line 471, in do_socket
OverflowError: cannot fit 'int' into an index-sized integer

Hi. I'm using a 64-bit distribution of Python. Installing px from PyPI fails:

>pip install px-proxy
Collecting px-proxy
  Could not find a version that satisfies the requirement px-proxy (from versions: )
No matching distribution found for px-proxy

I think the solution will be to publish a 64-bit wheel -win32_amd64.whl or a source distribution https://pypi.org/project/px-proxy/#files

I'm currently building an internal Chocolatey environment. During creation of a px-0.3.0 package I realized that I cannot see any ouput from my shimed px.exe. Shiming is the chocolated way of putting installed programs in the PATH. To avoid cluttering of the PATH a new small .exe-File with the same name (px.exe) is generated at a location within the PATH. This exe redirects any console input/output to the original installed application outside of the PATH. Normally this works quite well, but not for px.

I think the reason is how attachConsole works!? It looks for an parant cmd/cmd.exe and attaches to this console. It will never find a parent powershell.exe, git-cmd.exe or the shimed px.exe.

Maybe the first parsecli()-Call should stick to the old fashioned way of using the console!?

Hi, is there something wrong i'm doing or it's not working?

Below my config:

[proxy]
#server =
port = 3128
listen = 127.0.0.1
allow = *.*.*.*
gateway = 0
hostonly = 0
#noproxy = 127.0.0.1
#useragent = 

[settings]
workers = 2
threads = 5
idle = 30
socktimeout = 5.0
proxyreload = 60
foreground = 0
log = 1

And IE settings:

Currently while using px with ntlmv2 proxy server we get error from curl commands that "Your credentials could not be authenticated: "Another round of authentication required.". You will not be permitted access until your credentials can be verified.
Does it support NTLMV2 auth for proxy server?

2 Bugfixes:

• In my environment, configparser does not know "default_section", not sure if it's in general like this. I disbaled this line via comment.
• When using "noproxy" and "get_destination" trys to resolv the ip address, I'm running into a timeout (exception) because of "handle_one_request". This behaviour makes px to timeout all internet requests, because my local DNS isn't able to resolv internet addresses. In my environment resolving internet addresses is done on proxy side. That's why I added an own expception there.

1 Enhancement:

• Added possibility to set "--listen", "--port" and "--config" via commandline/arguments

--- px.py	2018-01-17 17:14:16.692200100 +0100
+++ px.py	2018-01-17 17:20:24.890200100 +0100
@@ -495,7 +495,10 @@
 
             dprint(netloc)
             spl = netloc.split(":", 1)
-            addr = socket.getaddrinfo(spl[0], int(spl[1]))
+            try:
+		addr = socket.getaddrinfo(spl[0], int(spl[1]))
+            except:
+		addr = ""
             if len(addr) and len(addr[0]) == 5:
                 ipport = addr[0][4]
                 dprint("%s => %s + %s" % (self.path, ipport, path))
@@ -622,9 +625,13 @@
     global MAX_WORKERS
     global PORT
 
+    for i in range(len(sys.argv)):
+        if "--config=" in sys.argv[i]:
+            INI = sys.argv[i].split("=")[1]
+    
     if os.path.exists(INI):
         config = configparser.ConfigParser()
-        config.set(config.default_section, "allow", "*.*.*.*")
+        #config.set(config.default_section, "allow", "*.*.*.*")	//Produces Error
         config.read(INI)
 
         if "proxy" in config.sections():
@@ -689,6 +696,13 @@
             parsenoproxy(sys.argv[i].split("=")[1])
         elif "--allow=" in sys.argv[i]:
             parseallow(sys.argv[i].split("=")[1])
+        elif "--listen=" in sys.argv[i]:
+            LISTEN = sys.argv[i].split("=")[1]
+        elif "--port=" in sys.argv[i]:
+            try:
+		PORT = int((sys.argv[i].split("=")[1]))
+            except:
+		pass
 
     if "--gateway" in sys.argv:
         LISTEN = ''

Got this error :

Traceback (most recent call last):
  File "px.py", line 606, in <module>
    runpool()
  File "px.py", line 451, in runpool
    httpd = ThreadedTCPServer((GATEWAY, PORT), Proxy)
  File "c:\PORT-STC\opt\python3\lib\socketserver.py", line 430, in __init__
    self.server_bind()
  File "c:\PORT-STC\opt\python3\lib\socketserver.py", line 444, in server_bind
    self.socket.bind(self.server_address)
OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

I'd say it's because I'm not Administrator my my PC but I'm not sure...

I run in a corporate environment and I have set up the px.ini file correctly (I hope!). The error shows up right at the start of px execution.

In "get_destination" please add ftp like this:

if not port:
    if parse.scheme == "http":
        port = 80
    elif parse.scheme == "https":
        port = 443
    elif parse.scheme == "ftp":
        port = 21

I get the following error for both ca5d1fb and 26a98ba builds:

Process-1: MainThread: 1526291786: attach_console: Attaching to console 3684
Process-1: MainThread: 1526291786: parse_proxy: [('wwsgwy', 8080)]
Serving at 127.0.0.1:3128 proc Process-1
Process-1: MainThread: 1526291786: parse_config: proxy:server = wwsgwy:8080
Process-1: MainThread: 1526291786: parse_config: proxy:listen = 127.0.0.1
Process-1: MainThread: 1526291786: parse_config: proxy:port = 3128
Process-1: MainThread: 1526291786: parse_config: proxy:gateway = 0
Process-1: MainThread: 1526291786: parse_config: proxy:allow = ...
Process-1: MainThread: 1526291786: parse_config: proxy:noproxy =
Process-1: MainThread: 1526291786: parse_config: proxy:useragent =
Process-1: MainThread: 1526291786: parse_config: proxy:hostonly = 0
Process-1: MainThread: 1526291786: parse_config: settings:workers = 2
Process-1: MainThread: 1526291786: parse_config: settings:threads = 5
Process-1: MainThread: 1526291786: parse_config: settings:idle = 30
Process-1: MainThread: 1526291786: parse_config: settings:log = 0
Process-1: MainThread: 1526291786: parse_config: settings:socktimeout = 5.0
Process-1: MainThread: 1526291786: parse_config: settings:proxyreload = 60
Process-1: MainThread: 1526291786: parse_config: settings:foreground = 1
Process-1: MainThread: 1526291809: verify_request: Client address: 127.0.0.1
Process-1: Thread_0: 1526291809: do_GET: Entering
Process-1: Thread_0: 1526291809: do_GET: Path = http://hackage.haskell.org/package/ghcid-0.6.6.tar.gz
Process-1: Thread_0: 1526291809: do_transaction: Entering
Process-1: Thread_0: 1526291809: get_destination: hackage.haskell.org:80
Process-1: Thread_0: 1526291809: do_socket_connect: New connection: ('wwsgwy', 8080)
Process-1: Thread_0: 1526291809: do_proxy_type: Searching proxy type
Process-1: Thread_0: 1526291809: do_socket: Entering
Process-1: Thread_0: 1526291809: do_socket: GET http://hackage.haskell.org/package/ghcid-0.6.6.tar.gz HTTP/1.1
Process-1: Thread_0: 1526291809: do_socket: Sending User-Agent: cabal-install/1.24.0.0 (windows; i386)
Process-1: Thread_0: 1526291809: do_socket: Sending Host: hackage.haskell.org
Process-1: Thread_0: 1526291809: do_socket: Reading response code
Process-1: Thread_0: 1526291809: do_socket: Response code: 407 False
Process-1: Thread_0: 1526291809: do_socket: Reading response headers
Process-1: Thread_0: 1526291809: do_socket: Received Date: Mon, 14 May 2018 09:56:58 GMT
Process-1: Thread_0: 1526291809: do_socket: Received Content-Type: text/html
Process-1: Thread_0: 1526291809: do_socket: Received Cache-Control: no-cache
Process-1: Thread_0: 1526291809: do_socket: Received Content-Length: 3806
Process-1: Thread_0: 1526291809: do_socket: Received Proxy-Connection: Keep-Alive
Process-1: Thread_0: 1526291809: do_socket: Received Proxy-Authenticate: sanitized (4)
Process-1: Thread_0: 1526291809: do_socket: Received Proxy-Authenticate: sanitized (27)
Process-1: Thread_0: 1526291809: do_socket: Reading response data
Process-1: Thread_0: 1526291809: do_socket: Content length 3806
Process-1: Thread_0: 1526291809: do_proxy_type: Auth mechanisms: NTLM Basic realm="MWG NTLM Auth"
Process-1: Thread_0: 1526291809: do_proxy_type: Selected: {('wwsgwy', 8080): 'NTLM'}
Process-1: Thread_0: 1526291809: get_response: winkerberos SSPI
Process-1: Thread_0: 1526291809: do_socket: Entering
Process-1: Thread_0: 1526291809: do_socket: GET http://hackage.haskell.org/package/ghcid-0.6.6.tar.gz HTTP/1.1
Process-1: Thread_0: 1526291809: do_socket: Sending User-Agent: cabal-install/1.24.0.0 (windows; i386)
Process-1: Thread_0: 1526291809: do_socket: Sending Host: hackage.haskell.org
Process-1: Thread_0: 1526291809: do_socket: Sending extra Proxy-Authorization: sanitized len(77)
Process-1: Thread_0: 1526291809: do_socket: Reading response code
Process-1: Thread_0: 1526291809: do_socket: Response code: 407 False
Process-1: Thread_0: 1526291809: do_socket: Reading response headers
Process-1: Thread_0: 1526291809: do_socket: Received Date: Mon, 14 May 2018 09:56:59 GMT
Process-1: Thread_0: 1526291809: do_socket: Received Content-Type: text/html
Process-1: Thread_0: 1526291809: do_socket: Received Cache-Control: no-cache
Process-1: Thread_0: 1526291809: do_socket: Received Content-Length: 0
Process-1: Thread_0: 1526291809: do_socket: Received Proxy-Connection: Keep-Alive
Process-1: Thread_0: 1526291809: do_socket: Received Proxy-Authenticate: sanitized (69)
Process-1: Thread_0: 1526291809: do_socket: Reading response data
Process-1: Thread_0: 1526291809: do_transaction: Auth required
Process-1: Thread_0: 1526291809: do_transaction: Challenged
Process-1: Thread_0: 1526291809: get_response: winkerberos SSPI
Traceback (most recent call last):
File "px.py", line 272, in get_response
winkerberos.GSSError: SSPI: InitializeSecurityContext: The token supplied to the function is invalid

Process-1: Thread_0: 1526291809: do_transaction: Bad NTLM response
Process-1: Thread_0: 1526291809: do_GET: Error 503
Process-1: Thread_0: 1526291809: log_message: code 503, message Service Unavailable
Process-1: Thread_0: 1526291809: log_message: "GET http://hackage.haskell.org/package/ghcid-0.6.6.tar.gz HTTP/1.1" 503 -
Process-1: Thread_0: 1526291809: do_GET: Done

After noticing that px was not running on startup I checked the registry and found that the following command was added:

c:\users\current_user\appdata\local\programs\python\python37-32\python.exe "C:\Users\current_user\AppData\Local\Programs\Python\Python37-32\Scripts\px"

This command, however, fails when executed because the px file is an executable (not a script). It probably should be executed with the following command:

C:\Users\current_user\AppData\Local\Programs\Python\Python37-32\Scripts\px

I installed Px using pip and Python 3.7 on a Windows 7 machine.

Hi,

Using latest release, on windows, got the error in every request:

MainProcess: Thread_0: 1520419833: do_socket: Reading response code
MainProcess: Thread_0: 1520419833: do_socket: Response code: 407 False
MainProcess: Thread_0: 1520419833: do_socket: Reading response headers
MainProcess: Thread_0: 1520419833: do_socket: Received header Via = 1.1 10.0.3.5 (McAfee Web Gateway 7.7.2.7.0.24770)
MainProcess: Thread_0: 1520419833: do_socket: Received header Date = Wed, 07 Mar 2018 10:50:34 GMT
MainProcess: Thread_0: 1520419833: do_socket: Received header Content-Type = text/html
MainProcess: Thread_0: 1520419833: do_socket: Received header Cache-Control = no-cache
MainProcess: Thread_0: 1520419833: do_socket: Received header Content-Length = 3887
MainProcess: Thread_0: 1520419833: do_socket: Received header Proxy-Connection = Keep-Alive
MainProcess: Thread_0: 1520419833: do_socket: Received header Proxy-Authenticate = Negotiate
MainProcess: Thread_0: 1520419833: do_socket: Received header Proxy-Authenticate = NTLM
MainProcess: Thread_0: 1520419833: do_socket: Received header Proxy-Authenticate = Basic realm="Proxy Authentication"
MainProcess: Thread_0: 1520419833: do_socket: Reading response data
MainProcess: Thread_0: 1520419833: do_socket: Content length 3887
MainProcess: Thread_0: 1520419833: do_transaction: Auth required
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 59105)
Traceback (most recent call last):
  File "socketserver.py", line 639, in process_request_thread
  File "socketserver.py", line 361, in finish_request
  File "socketserver.py", line 696, in __init__
  File "http\server.py", line 418, in handle
  File "px.py", line 275, in handle_one_request
  File "http\server.py", line 406, in handle_one_request
  File "px.py", line 614, in do_GET
  File "px.py", line 551, in do_transaction
IndexError: list index out of range

I'm watching in wireshark as wget attempts to use px to connect to intranet machines, but the requests don't have the ntlm credentials in them. This is on windows 7 with a mingw64 installation

I run px on my laptop and connect to it from VMs running in VMware Workstation on my laptop. This works by setting gateway = 1 in px.ini. Unfortunately, I think what happens when gateway = 1 is that it binds to 0.0.0.0. Unfortunately, this is triggering Windows Firewall to block communication to the TCP listening socket when I am connected to our corporate VPN, since the VPN adapter is considered a "private" network according to domain policy.

If I could tell px to listen just on my VMware Workstation's host-only network (192.168.95.1), then I think I could avoid these Windows Firewall issues. I don't need px to act as a proxy for my laptop's host OS, just for all the VMs.

Something like a bind_ips = 192.168.95.1,127.0.0.1 setting would be perfect.

Hi!

It would be nice to have a downloadable binary distribution. I guess not everybody is willing to install python and components to build the tool.

Thanks

please consider providing a complete px.ini file that gets output when running the binary download with all the options either commented out or set to their defaults. As it is now you have to guess at what the format should be.

Executing build.bat in HEAD gives me:

Unable to find "c:\Miniconda\Lib\site-packages\tld\res\effective_tld_names.dat.txt" when adding binary and data files.

And no px.exe is generated.

When I remove this dependency to miniconda, build.bat works as expected.

Is this file really needed?

One cool feature of Cntlm (and most other proxies) is the ability to ignore certain IP addresses/ranges and hostnames/ranges. e.g., in Cntlm, I could do this:

NoProxy localhost,127.0.0.*,*.corporatenetwork.com

This is a critical feature because without it, I can't force certain IPs and hostnames to resolve locally.

During the installation, following the instructions from README

# download master
python setup.py install

the installation breaks as it requires README.txt file which is not included in the repository.

When replacing both occurrences of the README.txt with README.md in the setup.py file, the installation was successful.

If this is the intended use, I can create the pull request.

Can you add a license to this repo because "no license" means strong copyright. My company has strong OSS policies that prevent me to use your tool.
Please, see this article from Github for more info: https://choosealicense.com/no-license/

I propose as background information to add a link to https://msdn.microsoft.com/en-us/library/dd925287.aspx which explains the sequence of the NTLM authentication.

Furthermore you should mention (e.g. as an ini file comment), that the log files are written in to the directory where px got started and that previous logs get overwritten at every start of the tool.

Otherwise thanks fot the cool piece of Software!

Hello,

can you explain in detail how to make PX work for Windows 10? I did the following:

Open px.ini and add my proxy under server=
Added allow = 127.0.0.1 + my own ip from ipconfig /all
Save px.ini
Run build.bat

I see a terminal for a blink of an eye and then it disappears. What am I doing wrong?

Hi, geno. I am using a continuous integration tool called Concourse that has a command line application known as Fly. Fly is a Linux tool, so it reads proxy settings from the HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables. I am running Fly from within a Windows 10 VM running on my workstation.

Settings:

Note that 10.<redacted> in both cases is the single IP address of the Concourse server on my corporate network.

When I run Fly in this manner, I receive the following strange HTTP response:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
        <title>Error response</title>
    </head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 501</p>
        <p>Message: Unsupported method ('PUT').</p>
        <p>Error code explanation: HTTPStatus.NOT_IMPLEMENTED - Server does not support this operation.</p>
    </body>
</html>

However, if I simply add 10.<redacted> to the NO_PROXY environment variable and try again, Fly works without issue. It seems like the only difference between my two attempts is that the first goes through px and the second doesn't.

Partial log output demonstrating that GET works fine but PUT doesn't:

192.168.95.129 - - [14/Mar/2017 08:40:33] "GET http://10.<redacted>:8080/api/v1/info HTTP/1.1" 200 -
...
192.168.95.129 - - [14/Mar/2017 08:40:35] code 501, message Unsupported method ('PUT')
192.168.95.129 - - [14/Mar/2017 08:40:35] "PUT http://10.<redacted>:8080/api/v1/<redacted> HTTP/1.1" 501 -

Does px support PUT? Do I need to configure something somewhere?

I'm currently trying to use WPAD/PAC support on Win10 clients and I get the following log:

MainProcess: MainThread: 1523945168: attach_console: No parent console to attach to
MainProcess: MainThread: 1523945168: parse_config: Turning allow off
MainProcess: MainThread: 1523945168: load_proxy: AutoConfigURL = http://info-pac.rwe.com/innogy.pac
MainProcess: MainThread: 1523945168: load_proxy: Proxy mode = 3
Serving at :3128 proc MainProcess
MainProcess: MainThread: 1523945168: parse_config: proxy:server = 
MainProcess: MainThread: 1523945168: parse_config: proxy:listen = 
MainProcess: MainThread: 1523945168: parse_config: proxy:port = 3128
MainProcess: MainThread: 1523945168: parse_config: proxy:gateway = 0
MainProcess: MainThread: 1523945168: parse_config: proxy:hostonly = 1
MainProcess: MainThread: 1523945168: parse_config: proxy:allow = 
MainProcess: MainThread: 1523945168: parse_config: proxy:noproxy = 
MainProcess: MainThread: 1523945168: parse_config: proxy:useragent = 
MainProcess: MainThread: 1523945168: parse_config: settings:workers = 2
MainProcess: MainThread: 1523945168: parse_config: settings:threads = 5
MainProcess: MainThread: 1523945168: parse_config: settings:idle = 30
MainProcess: MainThread: 1523945168: parse_config: settings:socktimeout = 5.0
MainProcess: MainThread: 1523945168: parse_config: settings:proxyreload = 60
MainProcess: MainThread: 1523945168: parse_config: settings:foreground = 0
MainProcess: MainThread: 1523945168: parse_config: settings:log = 0
MainProcess: MainThread: 1523945204: verify_request: Client address: 127.0.0.1
MainProcess: MainThread: 1523945204: verify_request: Host-only IP allowed
MainProcess: Thread_0: 1523945204: do_CONNECT: Entering
MainProcess: Thread_0: 1523945204: do_transaction: Entering
MainProcess: Thread_0: 1523945204: get_destination: chocolatey.org:443
MainProcess: Thread_0: 1523945204: load_proxy: Skip proxy refresh
MainProcess: Thread_0: 1523945204: winhttp_find_proxy_for_url: WinHttpGetProxyForUrl error 6
MainProcess: Thread_0: 1523945204: find_proxy_for_url: Proxy found: 
MainProcess: Thread_0: 1523945204: do_transaction: No proxy server specified and not in noproxy list
MainProcess: Thread_0: 1523945204: do_CONNECT: Error 501
MainProcess: Thread_0: 1523945204: log_message: code 501, message Not Implemented
MainProcess: Thread_0: 1523945204: log_message: "CONNECT chocolatey.org:443 HTTP/1.1" 501 -
MainProcess: Thread_0: 1523945204: do_CONNECT: Transferred 0 bytes
MainProcess: Thread_0: 1523945204: do_CONNECT: Done

I tried to debug myself, but was not able to figure out why WinHttpGetProxyForUrl() fails with a ERROR_INVALID_HANDLE (6). The function WinHttpOpen() returns a valid handle! What other handle could be invalid?

I googled for other winhttp+ctypes examples on the web and they fail also! Same error at the same location. Any idea what could be different at our setup!? I can reproduce this on multiple Win10 clients.

I'm a little bit lost now... :-(

I want to install a package via apt on my Ubuntu 18.04 Vagrant machine. It takes very long until [Waiting for headers] disappears and the installation begins. I'm running Windows 7 and the version 2018-05-19 of px. Sometimes apt prints the error message Connection failed [IP: 10.0.2.2 3129]. The log then says:

MainProcess: Thread_4: 1526995974: handle_one_request: Host disconnected
MainProcess: Thread_4: 1526995974: handle_one_request: Host disconnected: 2
MainProcess: Thread_4: 1526995974: handle_one_request: Host disconnected: 3
MainProcess: Thread_4: 1526995974: handle_one_request: Closed connection to avoid infinite loop

If I switch back to Cntlm everything works normal.

MainProcess: MainThread: 1526995125: attach_console: Attaching to console 8952
MainProcess: MainThread: 1526995125: parse_proxy: [('proxy01.example.com', 8080)]
Serving at :3129 proc MainProcess
MainProcess: MainThread: 1526995125: parse_config: proxy:server = proxy01.example.com:8080
MainProcess: MainThread: 1526995125: parse_config: proxy:listen = 
MainProcess: MainThread: 1526995125: parse_config: proxy:port = 3129
MainProcess: MainThread: 1526995125: parse_config: proxy:gateway = 1
MainProcess: MainThread: 1526995125: parse_config: proxy:hostonly = 0
MainProcess: MainThread: 1526995125: parse_config: proxy:allow = 127.0.0.1,10.0.2.0/24,192.168.56.0/24
MainProcess: MainThread: 1526995125: parse_config: proxy:noproxy = 127.0.0.1,10.0.0.0/8,192.168.0.0/16
MainProcess: MainThread: 1526995125: parse_config: proxy:useragent = 
MainProcess: MainThread: 1526995125: parse_config: settings:workers = 1
MainProcess: MainThread: 1526995125: parse_config: settings:threads = 5
MainProcess: MainThread: 1526995125: parse_config: settings:idle = 30
MainProcess: MainThread: 1526995125: parse_config: settings:socktimeout = 5.0
MainProcess: MainThread: 1526995125: parse_config: settings:proxyreload = 60
MainProcess: MainThread: 1526995125: parse_config: settings:foreground = 0
MainProcess: MainThread: 1526995125: parse_config: settings:log = 0
MainProcess: MainThread: 1526995125: detach_console: Freed console successfully
MainProcess: MainThread: 1526995163: verify_request: Client address: 127.0.0.1
MainProcess: Thread_0: 1526995163: do_GET: Entering
MainProcess: Thread_0: 1526995163: do_GET: Path = http://archive.ubuntu.com/ubuntu/pool/universe/0/0ad-data/0ad-data_0.0.22-1_all.deb
MainProcess: Thread_0: 1526995163: do_transaction: Entering
MainProcess: Thread_0: 1526995163: get_destination: archive.ubuntu.com:80
MainProcess: Thread_0: 1526995163: get_destination: http://archive.ubuntu.com/ubuntu/pool/universe/0/0ad-data/0ad-data_0.0.22-1_all.deb => ('91.189.88.149', 80) + /ubuntu/pool/universe/0/0ad-data/0ad-data_0.0.22-1_all.deb
MainProcess: Thread_0: 1526995163: do_socket_connect: New connection: ('proxy01.example.com', 8080)
MainProcess: Thread_0: 1526995163: do_proxy_type: Searching proxy type
MainProcess: Thread_0: 1526995163: do_socket: Entering
MainProcess: Thread_0: 1526995163: do_socket: GET http://archive.ubuntu.com/ubuntu/pool/universe/0/0ad-data/0ad-data_0.0.22-1_all.deb HTTP/1.1
MainProcess: Thread_0: 1526995163: do_socket: Sending Host: archive.ubuntu.com
MainProcess: Thread_0: 1526995163: do_socket: Sending Range: bytes=27852430-
MainProcess: Thread_0: 1526995163: do_socket: Sending If-Range: Sat, 28 Oct 2017 18:04:50 GMT
MainProcess: Thread_0: 1526995163: do_socket: Sending User-Agent: Debian APT-HTTP/1.3 (1.6.1)
MainProcess: Thread_0: 1526995163: do_socket: Reading response code
MainProcess: Thread_0: 1526995163: do_socket: Response code: 407 False
MainProcess: Thread_0: 1526995163: do_socket: Reading response headers
MainProcess: Thread_0: 1526995163: do_socket: Received Proxy-Authenticate: sanitized (9)
MainProcess: Thread_0: 1526995163: do_socket: Received Proxy-Authenticate: sanitized (4)
MainProcess: Thread_0: 1526995163: do_socket: Received Date: Tue, 22 May 2018 13:19:23 GMT
MainProcess: Thread_0: 1526995163: do_socket: Received Cache-Control: no-cache
MainProcess: Thread_0: 1526995163: do_socket: Received Pragma: no-cache
MainProcess: Thread_0: 1526995163: do_socket: Received Content-Type: text/html; charset="UTF-8"
MainProcess: Thread_0: 1526995163: do_socket: Received Content-Length: 2528
MainProcess: Thread_0: 1526995164: do_socket: Received Accept-Ranges: none
MainProcess: Thread_0: 1526995164: do_socket: Received Proxy-Connection: keep-alive
MainProcess: Thread_0: 1526995164: do_socket: Reading response data
MainProcess: Thread_0: 1526995164: do_socket: Content length 2528
MainProcess: Thread_0: 1526995164: do_proxy_type: Auth mechanisms: Negotiate NTLM 
MainProcess: Thread_0: 1526995164: do_proxy_type: Selected: {('proxy01.example.com', 8080): 'NTLM'}
MainProcess: Thread_0: 1526995164: get_response_sspi: pywin32 SSPI
MainProcess: Thread_0: 1526995164: do_socket: Entering
MainProcess: Thread_0: 1526995164: do_socket: GET http://archive.ubuntu.com/ubuntu/pool/universe/0/0ad-data/0ad-data_0.0.22-1_all.deb HTTP/1.1
MainProcess: Thread_0: 1526995164: do_socket: Sending Host: archive.ubuntu.com
MainProcess: Thread_0: 1526995164: do_socket: Sending Range: bytes=27852430-
MainProcess: Thread_0: 1526995164: do_socket: Sending If-Range: Sat, 28 Oct 2017 18:04:50 GMT
MainProcess: Thread_0: 1526995164: do_socket: Sending User-Agent: Debian APT-HTTP/1.3 (1.6.1)
MainProcess: Thread_0: 1526995164: do_socket: Sending extra Proxy-Authorization: sanitized len(85)
MainProcess: Thread_0: 1526995164: do_socket: Reading response code
MainProcess: Thread_0: 1526995164: do_socket: Response code: 407 False
MainProcess: Thread_0: 1526995164: do_socket: Reading response headers
MainProcess: Thread_0: 1526995164: do_socket: Received Proxy-Authenticate: sanitized (301)
MainProcess: Thread_0: 1526995164: do_socket: Received Date: Tue, 22 May 2018 13:19:24 GMT
MainProcess: Thread_0: 1526995164: do_socket: Received Cache-Control: no-cache
MainProcess: Thread_0: 1526995164: do_socket: Received Pragma: no-cache
MainProcess: Thread_0: 1526995164: do_socket: Received Content-Type: text/html; charset="UTF-8"
MainProcess: Thread_0: 1526995164: do_socket: Received Content-Length: 2528
MainProcess: Thread_0: 1526995164: do_socket: Received Accept-Ranges: none
MainProcess: Thread_0: 1526995164: do_socket: Received Proxy-Connection: keep-alive
MainProcess: Thread_0: 1526995164: do_socket: Reading response data
MainProcess: Thread_0: 1526995164: do_socket: Content length 2528
MainProcess: Thread_0: 1526995164: do_transaction: Auth required
MainProcess: Thread_0: 1526995164: do_transaction: Challenged
MainProcess: Thread_0: 1526995164: get_response_sspi: pywin32 SSPI
MainProcess: Thread_0: 1526995164: do_socket: Entering
MainProcess: Thread_0: 1526995164: do_socket: GET http://archive.ubuntu.com/ubuntu/pool/universe/0/0ad-data/0ad-data_0.0.22-1_all.deb HTTP/1.1
MainProcess: Thread_0: 1526995164: do_socket: Sending Host: archive.ubuntu.com
MainProcess: Thread_0: 1526995164: do_socket: Sending Range: bytes=27852430-
MainProcess: Thread_0: 1526995164: do_socket: Sending If-Range: Sat, 28 Oct 2017 18:04:50 GMT
MainProcess: Thread_0: 1526995164: do_socket: Sending User-Agent: Debian APT-HTTP/1.3 (1.6.1)
MainProcess: Thread_0: 1526995164: do_socket: Sending extra Proxy-Authorization: sanitized len(577)
MainProcess: Thread_0: 1526995164: do_socket: Reading response code
MainProcess: Thread_0: 1526995164: do_socket: Response code: 200 False
MainProcess: Thread_0: 1526995164: do_socket: Reading response headers
MainProcess: Thread_0: 1526995164: do_socket: Received Date: Tue, 22 May 2018 13:19:24 GMT
MainProcess: Thread_0: 1526995164: do_socket: Received Server: Apache/2.4.18 (Ubuntu)
MainProcess: Thread_0: 1526995164: do_socket: Received Last-Modified: Sat, 28 Oct 2017 18:04:50 GMT
MainProcess: Thread_0: 1526995164: do_socket: Received ETag: "26273504-55c9f3dcdb480"
MainProcess: Thread_0: 1526995164: do_socket: Received Accept-Ranges: bytes
MainProcess: Thread_0: 1526995164: do_socket: Received Content-Length: 640103684
MainProcess: Thread_0: 1526995164: do_socket: Received Cache-Control: max-age=86400
MainProcess: Thread_0: 1526995164: do_socket: Received Keep-Alive: timeout=5, max=100
MainProcess: Thread_0: 1526995164: do_socket: Received Content-Type: application/x-debian-package
MainProcess: Thread_0: 1526995164: do_socket: Received Proxy-Connection: keep-alive
MainProcess: Thread_0: 1526995164: do_socket: Reading response data
MainProcess: Thread_0: 1526995164: do_socket: Content length 640103684

Is there any way to specify domain names for --noproxy instead of IP addresses or along with IP addresses?

I am trying to get this working on Phyton 2.7 64 bit. 64 bit versions of pyutils and pywin32 are installed. The program runs but when I actually get to using the proxy, I get the following error message and a subsequent 407 response from the proxy.

Traceback (most recent call last):
File "px.py", line 96, in create_challenge_response
error_msg, output_buffer = self.sspi_client.authorize(input_buffer)
File "C:\Python27\lib\site-packages\win32\lib\sspi.py", line 139, in authorize
sec_buffer_out)
error: (-2146893054, 'InitializeSecurityContext', 'The function requested is not supported')
127.0.0.1 - - [05/Jan/2017 12:02:28] code 407, message Proxy Authentication Required

Maybe also the possibility to add proxy autodiscovery (WPAD), which returns a PAC file.

I'm not sure howto exactly reproduce the error mentioned in #9 , but using the newest pywin32 from https://github.com/mhammond/pywin32 isn't causing any exceptions or errors so far in my environment.

EDIT:
OK, just saw you dropped pywin32 support at all. Well then, this isn't interesting anymore :-)

It'd be pretty neat if we could do a no proxy config based on domain names. The use case I have is that I don't want to go via PX for my intranet sites but I can't wildcard domain entries

Binary version of Px runs in the background already but a flag or config option should allow the script version to run in the background too. This will be useful if Px is run from source or installed via pip or other methods.

As a complement, the --quit flag should also be enhanced to work as expected in this mode.

I'm running into a similar kind of issue like #31. I have px "installed", but after every reboot px crashs with a popup window Failed to execute script px.

I have the feeling that the reasons are missing file permissions. When I "install" px, this is done with administrator rights, so the folder where px is installed is writable only for an administrator. But when px is started, this happens without admin rights. The strange thing is that px also crashes when installed without debug setting active, so nothing should be written in the folder. I checked the created px.ini and it's log=0 there.

When I start px.exe manually in an unelevated cmd.exe, it's all fine, no crash. But during boot, always a crash (without a log file, of course).

@genotrance: Any idea how to further debug this?

It's easy to download and run the binary version of Px. However, it's fairly common for power users who would be the typical audience for Px to have Python already installed. Being able to pip install px would be very convenient.

http://peterdowns.com/posts/first-time-with-pypi.html

px is already taken on pip so might have to call it px-proxy or similar.

Hi,

I've used pyinstaller to build px on Windows 7, using Python 3.6, I'm getting the following error while trying to connect to the proxy: ValueError year 3083 is out of range in sspi.py line 111.

Any ideas?

steps to reproduce

• start the px executable directly in Windows 7
• enter px --quit in cmd
• Px is not running

expected behaviour

• start the px executable directly in Windows 7
• enter px --quit in cmd
• Px is terminated

Nevertheless, thank you very much for sharing this AWESOME tool!

Hi,
virustotal reports a few issues with the binaries:
https://www.virustotal.com/de/file/95f52cec423181d0c59fbc867f1b9709cb847589fed64edb172e86e85c2d090e/analysis/1518603360/

The major players don't seem to recognize anything so I guess it's false positive but you should look into that.

Greetings
Klaas

Hi,

I wonder how Px is configured if it has been installed using "--install". Does it use the CLI parameters which have been specified together with --install or is Px expecting a config file in a certain location?

Can you please describe that in the README?

Great tool, anyway!

debug-Process-2.log

Px started manuallу with admin rights.
After the first connect attempt I always get the exception "list index out of range":

Exception happened during processing of request from ('127.0.0.1', 55607)
Traceback (most recent call last):
File "socketserver.py", line 639, in process_request_thread
File "socketserver.py", line 361, in finish_request
File "socketserver.py", line 696, in init
File "http\server.py", line 418, in handle
File "px.py", line 288, in handle_one_request
File "http\server.py", line 406, in handle_one_request
File "px.py", line 677, in do_CONNECT
File "px.py", line 563, in do_transaction
File "px.py", line 416, in do_socket
IndexError: list index out of range

The second attempt is always ok.