- From: Justin Dossey <
>
- To:
- Subject: [chef] Ruby, Chef, proxies
- Date: Thu, 23 Oct 2014 09:17:13 -0700
Hi all,
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 variable?
- If it does, does it respect the no_proxy (or NO_PROXY) environment variable?
Here's a gist of the code:
https://gist.github.com/justindossey/7c6e0a62ec34ce0bf317The 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 support.
- 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
--
Justin Dossey
Practice Owner
New Context Services, Inc
- [chef] Ruby, Chef, proxies, Justin Dossey, 10/23/2014
Archive powered by MHonArc 2.6.16.