Closed k-f closed 4 years ago
I'm not opposed to the idea of supporting PACs served over file://, but it does seem that Microsoft is against it (see https://blogs.msdn.microsoft.com/ieinternals/2013/10/11/understanding-web-proxy-configuration/ and https://gallery.technet.microsoft.com/scriptcenter/Resolving-Clients-fd2c140f). I've also heard that macOS doesn't support it either.
I don't fully understand the reasons why, but the blog suggests that this is about interoperability - i.e. some things silently break when given a file:// PAC URL, and so having Windows reject the file:// URL early on will prevent people from getting into this scenario.
I can imagine a similar situation where Alpaca users configure both their system proxy settings (for WinINET/Cocoa applications) and Alpaca (for command-line tools) to use a file:// URL, and run into issues. It's possible that this can be resolved by simply printing a warning message, assuming that's the only reason that Microsoft (and Apple) have dropped support for file://.
Fixed by #13
For circumstances where users need to tailor their pac file from the standard, do testing etc, the ability to specify
file://
type URI schemes would be very beneficial. Our team is working around this by locally serving a pac file