0

Standard corporate environment, forcing clients to got through a proxy server via a proxypac. In the OSX configuration is in the following format:

http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac

Trying to connect via CLI, for a homebrew install, and used (so far) the following options:

export http_proxy=http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac

export http_proxy=http://www.proxy.server.name:8080

export http_proxy=http://myusername:[email protected]:8080/proxy_pac_path_to_package.pac

export http_proxy=http://myusername:[email protected]:8080

with mypasswd special characters being mapped into their hex code, and with username using either the "simple" form, or the entire AD path, or the email, etc.

None of the above worked. Any idea about what I may be missing, from one's own experience through non-obvious things?

Improve this question
1
  • I'm voting to close this question as off-topic because it can no longer be reproduced.
    – DavidPostill ♦
    Oct 5, 2016 at 8:53

2 Answers 2

Reset to default
0

Since I don't have access to your particular corporate environment, I can't make a definitive diagnosis, but the first thing I'd try is exporting https_proxy and all_proxy with the same value (note that the https_proxy may not have an https: URL; it has whatever the http_proxy is). Your various selections of values were the correct ones to try (though I've seen very odd encodings of username/password, so I wouldn't write that off). I would make sure that Safari works through the proxy, and if you need to login to the proxy via Safari, you do so. If Safari isn't working through the proxy, there's basically zero chance that Homebrew will.

As a second thing to try (though this is voodoo and may just be cargo culting), you could try setting it, instead of to the http: schema, to the socks5: schema, otherwise leaving the rest of the URL the same. I've seen this work because certain proxies are more geared towards Windows clients and still have old code, and because of the poor record of interoperability between Windows versions' TCP stacks, SOCKS was more reliable.

Improve this answer
2
  • Thank you for the quick response. Here is what "throws me off: - all examples I have seen, so far, end at the FQDN:PORT config. For some reasons my proxy config, pushed from the enterprise, has the pac AFTER the port... and yes - Safari and Chrome work fine. I will try your other suggestions - https makes the most sense, next
    – Papi Antoniadis
    Sep 22, 2016 at 15:14
  • Pardon if I'm misunderstanding, but the path to the PAC has to go after the FQDN:PORT, because the format of a URL must be schema://username@host:port/path/name (with some of those items being optional). If the PAC came before the port, it wouldn't be a port anymore, but an addition to the path name.
    – Trey
    Sep 22, 2016 at 17:56
0

Unbelievable!!! A huge DUH on my part: had two iTerm windows opened in the same time - I was doing the export http_proxy in one, from the CLI, and testing connectivity in the other (which was running another shell session, of course, with no awareness of the exported variables in the one I was making changes in)... can't believe how stupid this was. Sorry for all the noise... and thanks to @Trey to assuming I was not an idiot :-)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .