My workplace has a fairly complicated PAC file for determining which proxy HTTP(S) traffic should use to get to various internal and external networks. This is fine for Chrome, Safari, etc., but awful for commandline tools (curl, most scripting language HTTP libraries). The normal solution is set various environment variables like HTTP_PROXY to proxy.example.com:8888, but that doesn't work with PAC. Instead, most of us run some kind of PAC-aware proxy on localhost and send everything through that.
My question is, why is any of this necessary in the first place? OSX is fine evaluating PAC rules for its own connections, but curl, etc. can't? networksetup gives me this:
$ networksetup -listallhardwareports
Hardware Port: Wi-Fi
Device: en0
Ethernet Address: ...
$ networksetup -getproxyautodiscovery Wi-Fi
Auto Proxy Discovery: On
I took that to mean that anything going through en0 should have proxy auto-discovery. Is that wrong? Does proxy auto-discovery and auto-configuration take place at a higher level that's only accessible through Apple APIs (which browsers, etc. use)? (And if so, how can I access them?)
OS X 10.11 and up include nscurl, which is a simplified curl-like utility that uses the platform APIs for network transfer. I would expect it to support proxies as well as any OS X app, although it doesn't have all the features of full curl