I work at a place that requires that I use a proxy to access the Internet.
Support for proxies in Ruby stuff is uneven, probably because most people
don’t have to support proxies.
I wrote a script to test different methods of GETting a public page in
Ruby. It addresses the questions:
- Does this method respect the http_proxy (or HTTP_PROXY) environment
- If it does, does it respect the no_proxy (or NO_PROXY) environment
Here’s a gist of the code:
The output on my system is posted as a comment.
I’d love to see other clients in here! I tried to stick to stuff that was
installed via ChefDK.
A couple of things I want to highlight about the test:
- In ruby’s standard Net::HTTP, the way you perform the request strongly
influences whether your proxy is respected. Net::HTTP.get_request and
Net::HTTP.get do not honor proxies. Even Net::HTTP.start() doesn’t honor
your proxy. You have to do Net::HTTP.new().start in order to get proxy
- open-uri is proxy-friendly (but you give up a bit of control of
request headers, etc)
- Ruby doesn’t honor wildcards in the no_proxy or NO_PROXY environment
variable. Chef, however, does (in Chef::HTTP::BasicClient).
- I didn’t test Chef::HTTP::BasicClient because my test runs outside of
Chef, but I’m pretty sure it does the right thing.
If you want to run this, you need:
- ChefDK, or have the HTTP and Faraday gems installed;
- A Proxy server to use
New Context Services, Inc