-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
get_destination for local server not using direct connection since 0.8.0 #161
Comments
PAC files specified to Px (rather than in Internet Options) on Windows are now processed using QuickJS instead of WinHttp on v0.8.0+. This is because Windows doesn't like local PAC files anymore. Px had a goofy workaround to host the PAC file on its own web server but that was removed ever since QuickJS was required on non-Windows platforms to process PAC files and made for a simpler and consistent solution for local and remote files specified to Px. In your case, it is a URL but still leverages the QuickJS engine since it isn't configured in Internet Options. It will help to have more context on the v0.7.2 log - curious if the PAC file was loaded and processed by WinHttp. I'm also curious what the PAC file looks like and why WinHttp (assuming it was processing the PAC file) felt it was a direct connection, whereas QuickJS thinks otherwise. It is likely the processing of the return value from the PAC file processing is still wrong. Adding |
The minified, anonymized
The additional debug line can only be added in version 0.8.0+, on version 0.7.2 you have to point me to a different file as pac.py does not exist. |
Thanks for taking the time to provide this info. The debug output is only needed for v0.8.2. The older version doesn’t have access to the PAC file since WinHttp does all that. Which if statement should your server match in this list? First thought is the second last one but that is only matched when you use the actual IP itself. Since everything is xx.xyz, I’m not able to tell what is really happening here. |
alright, v0.8.2 outputs the expected I do not know if I can tell you the details of the I also tested v0.7.2 with a
EDIT: after some more testing, v0.7.2 uses the proxy now, too EDIT: with |
That is what I suspected. Lines 61 to 63 in 39df09c
Either QuickJS doesn't handle the |
Looks like it is QuickJS - I tested the above function in Chrome's console and it returned true for "server01" but QuickJS returns false. import quickjs
f = quickjs.Function("isPlainHostName", """
function isPlainHostName(host) {
return host.search("(\\.)|:") == -1;
}
""")
print(f("server01")) Prints False. |
Maybe it is an escaping issue or an issue with the Python wrapper of QuickJS not forwarding the escaping correctly. I do not know exactly how Python escapes characters but if you use three backslashes it works and matches dots or colons (just as intended). Maybe you have to do some kind of multiple escaping due to the layering between wrapper and quickjs. try the following import quickjs
f = quickjs.Function("isPlainHostName", """
function isPlainHostName(host) {
return host.search("(\\\.)|:") == -1;
}
""")
print(f("server01")) Prints |
This should be fixed in v0.8.4. |
Hello,
we have our local server
server01
and until version 0.7.2 it uses aDirect connection
to that serversince version 0.8.0 it uses the proxy, which it should not use (logging of version 0.8.3 because of #160)
Is this as intended that it now using the proxy instead of the direct connection?
The text was updated successfully, but these errors were encountered: