VistaLover

... Consult previously linked documentation, e.g. https://findproxyforurl.com/pac-functions/ In your sample case, and to include all subdomains, something like: if (dnsDomainIs(host, ".example.com") or (the one you found yourself): if (shExpMatch(host, "*.example.com") Both two above will include, of course, "www.example.com" as hostname, but won't include just "example.com" ; in such a case: if (dnsDomainIs(host, "example.com") || dnsDomainIs(host, ".example.com") For a set of completely different domains, use the sample syntax above (using either "dnsDomainIs(host," or "shExpMatch(host," for your included hostnames) ... FWIW, below is a PAC script I was using in ca. 2010 to access UK TV channels (BBC iPlayer, ITV, Ch4 and some UK radio stations owned by Bauer): function FindProxyForURL(url, host) { alert('url: \'' + url + '\', host: \'' + host + '\''); if ( shExpMatch(host, "fig.bbc.co.uk") || shExpMatch(url, "*.edgesuite.net/*") || shExpMatch(url, "*.akamaized.net/*") || shExpMatch(url, "*.bbcfmt.vo.llnwi.net/*") || shExpMatch(url, "*.llnwd.net/*") || shExpMatch(url, "*playlists.bbc.co.uk/*") || shExpMatch(url, "*.bbc.co.uk/mediaselector/*") || shExpMatch(host, "*.bidi.bbc.co.uk") || shExpMatch(host, "*.bidi.live.bbc.co.uk") || shExpMatch(url, "*ais.channel4.com/*") || shExpMatch(url, "*mercury.itv.com/*") || shExpMatch(url, "*mediaplayer.itv.com/flash/playlists/*") || shExpMatch(url, "*magni.itv.com/*") || shExpMatch(url, "*tx.whatson.com/*") ) { return "PROXY 86.25.218.xxx:3128"; } else { return "DIRECT"; } } BTW, it's totally worthless today, so, hopefully, I won't get in trouble by just posting it here ; just a small note, though: shExpMatch(url, "*.bbc.co.uk/mediaselector/*") || At some point, Chromium and Firefox, for security/privacy reasons ( ), stopped supporting URL subdirectories inside the url RegExp syntax, so this filter isn't correct by recent PAC/browser standards ... ... In those cases, the sites are serving mixed content (some over HTTPS and some over plain HTTP) and this is considered bad web practice today (e.g., recent Chrome will block the insecure content by default) - if the insecure content (HTTP) is being served on the page from a third party domain, I don't see where your problem lies ; if they're indeed serving mixed content from the same first party domain, then what "external website" are you talking about there? In the last case, you could forward only the secure content over to ProxyMII via, e.g. if (shExpMatch(url, "https://*.example.com/*") || etc,, whereas non-secure content from "http://*.example.com/*" will be fetched directly through browser... ... What he meant was that non-tech users should be extra careful how they install+configure HTTPSProxy (basically, the user custom rules inside its config.ini file), because any potential errors there may and will result in loss of connection for the client app (browser) ... If you do want to talk about security per se, you are running Windows XP, aren't you? ... And a browser (360EEv13.5) based on old Chromium core (86), aren't you? In the same vein, ProxyMII uses a deprecated CPython version and also deprecated Python modules (because their current versions aren't compatible with that older Python and/or XP itself) to achieve its functions, so do you get the drift ? When I try the "legacy" login page, I'm redirected to a https://web1.carparts-cat.com/Login.aspx page; as I said, under Vista SP2 32-bit, ALL appear correct vis-à-vis the secure connection: What does an XP SP3 x86 user see in the above scenario? FWIW, "http://web1.carparts-cat.com/" ALWAYS redirects to HTTPS here, so what makes one believe the connection succeeds but data is transferred unencrypted?

... As I understood this, the suggestion was to use Thorium standalone (presumably because Thorium comes also with its own CA store/is less prone than 360EEv13.5 under WIndows XP to fail on secure connections... But yes, thanks to Anbima, last pages on this thread went like this: 360EEv13.5 standalone -> 360EEv13.5 + ProxyMII -> 360EEv13.5 + ProxyMII + Local PAC script -> 360EEv13.5 + ProxyMII + Local PAC script + Chromium extension(s) -> 360EEv13.5 + ProxyMII + Local PAC script (without extension) -> 360EEv13.5 + ProxyMII (standalone, without PAC script) -> 360EEv13.5 + ProxyMII + extension -> Thorium standalone (for his "problematic" HTTPS connections) -> exclusively Thorium-related queries -> ... IMHO, ProxyMII / ProxHTTPSProxy was the constituent with the lesser percentage in these recent discussions ; the "issue" could well have been posted in one of the 360EE threads ... FWIW, if the issue encountered is the infamous "red-X" instead of a green padlock on some HTTPS connections on 360EEv13.5 under XP, this is an already known "issue" and can well be a "red herring" (or not, but no-one posted something definitive on the matter...); IIRC, you can restore the padlock on these connections by running the 360chrome.exe executable in win2k compatibility (or something in this vein - have never faced this issue under Windows Vista SP2 x86 myself...).

... I guess "we"'re moving in circles here, aren't "we"? If you don't want to employ a local PAC script after all and you want to use ProxyMII in 360EE by selectively (manually) enabling it on the (now two) problem sites, no extension is required; the options have been already presented to you by both AstroSkipper and me: 1. Configure IE8 to use ProxyMII (its FrontServer) just for secure connections - then, manually enable this configuration in 360EE by setting "Proxy -> Use IE proxy" for the two "problem" sites, or 2. Configure 360EE to use ProxyMII (its FrontServer) directly (i.e. leaving IE8 out of this) and then manually enable this configuration, just for your two "problem" sites, by selecting "Proxy -> localhost:8079" (see image attachments in my previous reply just above) when visiting the affected sites ...

... However, yet another proof of how biased are most PM forum members towards "those XP users" ; the last comment on the thread you linked is by a member called "Night Wing"; he writes: His remark is totally out of context, though - but his hatred towards "XP users" is such that he can't even read right ; https://github.com/Feodor2/Mypal68/issues/366#issuecomment-1913684572 i.e. GitHub member "NS-Clone" was referring to JustOff's [old] "legacy" extension "Modify-HTTP-Response", which is indeed an XUL-type one, supported in Firefox (<=56), official Pale Moon and SeaMonkey, but NOT supported in Mypal68 ; IOW, Night Wing's last sentence is nothing more than a product of anti-XP "frenzy"...

OT: Most of the official Pale Moon forum(s) can be accessed and read anonymously ; it's only a small subset that indeed requires an account to be read, among them the "The Bulletin Board/Off-Topic" subforum (it's invisible to those browsing "The Bulletin Board" anonymously ) ...

... Not a coincidence, for sure , but this very same YT clip was the topic of a Pale Moon Forum thread that soon escalated to name-calling and bad-mouthing MSFN members using the New Moon browser on WinXP today ...

PSO is still compatible with 360EE (latest v2.5.21 is still on MV2) and has full support for PAC scripts: Just enter its Settings and create a new "Profile"; when prompted, select the "PAC profile" option and give this new profile an appropriate name (here: "Local PAC"); the screenshot is self-explanatory ...

... If you don't want to use a dedicated extension (and I simply find you're just being obstinate without a reason), I'll point you again to: https://issues.chromium.org/issues/40574814#comment23 For a PAC script like the one below: function FindProxyForURL(url, host) { if (shExpMatch(host, "example.com")) { return "PROXY localhost:8079"; } } go to an online base64 encoder and the result you'll get is the string: ZnVuY3Rpb24gRmluZFByb3h5Rm9yVVJMKHVybCwgaG9zdCkgewogaWYgKHNoRXhwTWF0Y2goaG9zdCwgImV4YW1wbGUuY29tIikpIHsKIHJldHVybiAiUFJPWFkgbG9jYWxob3N0OjgwNzkiOwogfQp9 Then, you should add to whatever 360 Loader/launcher you're using below cmdline parameter: --proxy-pac-url="data:application/x-javascript-config;base64,"ZnVuY3Rpb24gRmluZFByb3h5Rm9yVVJMKHVybCwgaG9zdCkgewogaWYgKHNoRXhwTWF0Y2goaG9zdCwgImV4YW1wbGUuY29tIikpIHsKIHJldHVybiAiUFJPWFkgbG9jYWxob3N0OjgwNzkiOwogfQp9 WFM: Caveats: You'll have to re-encode the PAC script and re-modify the switch whenever you add new domains; once the length of the cmdline switch gets too big for Windows Command Shell, this method will quit working... IOW: Use an extension! Addendum: I have verified myself the fact the Chinese must have done something wrong with their 360EE browser ; when you correctly configure IE (9 in my case - requires "unhealthy" syntax, i.e "file://", and NOT the "healthy" one, "file:///*") to use a locally hosted PAC file: and then instruct 360EE to "Use IE proxy", this configuration isn't applied ; OTOH, if you configure IE to use ProxyMII (FrontServer): and then instruct 360EE to "Use IE proxy", this configuration is applied (360EE uses ProxyMII - of course, for ALL secure URLs) ; in this latter case, you can avoid IE completely from acting as a MITM by configuring 360EE to use directly ProxyMII's FrontServer: and selecting this option from its Proxy Context Menu:

... Apologies are in order , it appears to be a "mea culpa" case; I have edited my original post accordingly :

... You're most welcome ! ... On the contrary, I became an avid fan of them since my beginnings in web navigation ; it was an era when full-blown VPNs were mostly unavailable to non-enterprises or too pricey for individuals, while open (read: misconfigured) HTTP(S) proxies could be easily found via a web search ; PACs offer a convenient way to selectively proxy only certain hosts/domains/etc. out of your total of web requests; was very handy on geo-fenced media portals/services in the ealry 2010s, where you had to (first identify and then) only proxy their geo-location checking scripts, with the media streams themselves (video and/or audio) being accessible "DIRECT"; now, 99.5% of these same media portals, free and paid for, geo-block fully their streams and also encrypt them with DRM ... PACs were also useful when you were employing a paid-for Proxy, but charged by proxy traffic or had quotas imposed on your use of it; by selectively proxying only those hosts that were inaccessible from your physical location, you could use less proxy bandwidth in a given time frame or squeeze more out of your proxy quota... This scenario involved use of proxies to unlock geo-fenced services (or ones regime-censored); if you were using a proxy for privacy reasons, then PACs were less applicable... Already known to me ; below, just for you, some PAC-related documentation, retrieved from my huge set of bookmarks: https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file https://learn.microsoft.com/el-gr/archive/blogs/ieinternals/understanding-web-proxy-configuration https://superuser.com/questions/191037/local-pac-file-url-format-that-works-with-ie-and-safari-windows https://blog.mikejmcguire.com/2014/05/07/using-proxy-auto-configuration-scripts-with-internet-explorer-11/ https://support.microsoft.com/en-us/topic/how-to-disable-automatic-proxy-caching-in-internet-explorer-92735c9c-8a26-d0d8-7f8a-1b46595cbaba http://io.mysq.to/pac-file-and-proxy-auto-switch-for-firefox-ie11-and-chrome https://calomel.org/proxy_auto_config.html https://www.websense.com/content/support/library/web/v76/pac_file_best_practices/pac_file_best_practices.pdf The IEx articles relate to configuring a Windows "system proxy" (which can then be used by Chromium and its derivatives) ... End of off-topic ...

@Anbima : It is still unclear to me (and probably to the rest of the members trying to help you ) what exactly you're trying to accomplish here ... 1. Are there specific HTTPS URLs that fail to load on your 360EEv13.5 copy under your XP set up? 2. Are you concerned that the browser will load HTTPS sites under plain HTTP (and you're afraid sensitive/private info of yours will be sniffed?) - it's my understanding that a secure connection will either succeed or fail altogether... AstroSkipper has provided you with one-click sloution(s) for when you want to go through the HTTPSProxy and when NOT (however, the proxy should always be running, you do get that ) ... As already told, the proxy comes with a "[BYPASS URL]" section inside its "config.ini" file, but this serves just to exclude a small number of sites from being accessed via the Proxy (the purpose of this tool being to access the overwhelming majority of the internet through it ). Can you be so kind as to link to that documentation? This is a local PAC file you're talking about... 1. Internet Explorer, unlike Mozilla Firefox "legacy" browsers (I have no idea what the case is with recent Firefox), has poor support for local PAC files loaded from disk (and configured via the "unhealthy"/legacy "file://" protocol) - so, you can still try to configure IE8's proxy settings via pointing it to your local PAC file, then configure 360EE to "Use IE proxy", but YMMV ... Later EDIT (2024-05-21): This approach doesn't seem to work ; IE8 applies the above configuration (use the local PAC file over "file://" protocol), however 360EE, for reasons best known to its Chinese devs , doesn't observe this configuration when instructed to "Use IE proxy" ... 2. Since Chrome v68, native support for loading local PAC scripts over the file:// protocol has been disabled and/or revoked: https://bugs.chromium.org/p/chromium/issues/detail?id=839566 Some mitigations are offered inside comments on that bug, e.g. https://issues.chromium.org/issues/40574814#comment9 https://issues.chromium.org/issues/40574814#comment23 You can learn more about configuring Proxies in Chrome/Chromium by reading this excellent documentation: https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md#proxy-support-in-chrome Since HTTPSProxy is a secure proxy, used to access HTTPS URLs, the PAC syntax you quoted is wrong; change PROXY to HTTPS, e.g. function FindProxyForURL(url, host) { alert('url: \'' + url + '\', host: \'' + host + '\''); if (shExpMatch(host, "example.com")) { return "PROXY localhost:8079"; } } The "alert" line can be omitted, but it's there to generate a message in the (browser) console when a site is being successfully proxied... EDIT/CORRECTION: ProxyMII (and similar projects based on Proxomitron) actually uses two local proxies (Rear+Front); client apps (e.g. browser) connect directly to the FrontServer (localhost:8079), which is plain HTTP, while the RearServer (localhost:8081) is the one facing the web; thus, my initial advice was wrong ; "PROXY localhost:8079" must indeed be used inside a PAC implementation - apologies for any inconvenience, "errare humanum est"... In conclusion, I've offered lots of relative info you could have found yourself already by "fine-tuned" web searches ... TL;DR; Use a proxy extension inside 360EEv13.5 that has support for local PAC files, if you wish for some form of automation...

... However, the 360EE variants have proxy settings of their own, different to the ones in Google Chrome/Chromium ... @Anbima : If you opt to use just ProxyMII, then configure your IE8 browser to use this HTTPSProxy just for "Secure:" connections and once this is done (you can exit IE8 now), you can configure 360EE to use that proxy via:

... But why is Thorium reported to be Google Chrome 109 there? For consistency, weren't you supposed to test the same Thorium variant but on different OS (XP vs 7) ?

In the repo copy maintained by roytam1, those two toolbar buttons were removed by Tobin himself as part of: https://github.com/roytam1/boc-uxp/commit/360e21244397998a6183d847c65eaeb3b48fbbe0 352 + <!-- XXXTobin: These need to be exterminated 353...381 382 + --> on Aug 8, 2020 ...

"Out-of-Band" new Supermium (122) release, to patch publicly disclosed Chromium vulnerabilities: https://github.com/win32ss/supermium/releases/tag/v122-r5 (in response to https://github.com/win32ss/supermium/issues/570 ) ; @nicolaasjan :