Using faraday 0.9.0 I get a conflict as faraday_middleware(0.9.0) needs
faraday < 0.9, >= 0.7.4.

Hopefully, this isn't a mistake like on #32. I'm having a problem with getting Faraday to follow redirects.

Without specifying the middleware, I receive a 301 and a location. Everything's a okay.

url = 'http://www.simplyhired.com/job-id/ep7zlwnw5b/director-of-jobs/'
conn1 = Faraday.new
conn1.get url
=> #<Faraday::Response:0x00000002142128
 @env=
  #<struct Faraday::Env
   method=:get,
   body="",
   url=#<URI::HTTP:0x0000000212c198 URL:http://www.simplyhired.com/job-id/ep7zlwnw5b/director-of-jobs/>,
   request=#<struct Faraday::RequestOptions params_encoder=nil, proxy=nil, bind=nil, timeout=nil, open_timeout=nil, boundary=nil, oauth=nil>,
   request_headers={"User-Agent"=>"Faraday v0.9.0"},
   ssl=#<struct Faraday::SSLOptions verify=nil, ca_file=nil, ca_path=nil, verify_mode=nil, cert_store=nil, client_cert=nil, client_key=nil, certificate=nil, private_key=nil, verify_depth=nil, version=nil>,
   parallel_manager=nil,
   params=nil,
   response=nil,
   response_headers=
    {"server"=>"shw",
     "date"=>"Sat, 08 Nov 2014 00:47:04 GMT",
     "content-type"=>"text/html; charset=UTF-8",
     "content-length"=>"0",
     "connection"=>"close",
     "set-cookie"=>
      "gc=1; expires=Sun, 09-Nov-2014 00:47:04 GMT; path=/, sess=ct%3D545d6808; path=/; domain=.simplyhired.com, sh3=id%3D273527411545d6808d42ea5.21614343%3Brv%3D208bbe4f%3Bcv%3D2; expires=Mon, 09-Nov-2015 00:47:04 GMT; path=/; domain=.simplyhired.com, sh2=cso%3D545d6808%3Bslu%3D0%3Bref%3Dsh; expires=Mon, 09-Nov-2015 00:47:04 GMT; path=/; domain=.simplyhired.com, shup=fvt%3D545d6808; expires=Mon, 08-Dec-2014 00:47:04 GMT; path=/, sh_uid=id%3A526650745545d6808d24440.69738556; expires=Thu, 07-Nov-2019 00:47:04 GMT; Max-Age=157680000; path=/; domain=.simplyhired.com, sh_sess=id%3A1415407624%2Csrc%3Aother%2Cnu%3A1; expires=Sat, 08-Nov-2014 01:17:04 GMT; Max-Age=1800; path=/; domain=.simplyhired.com",
     "cache-control"=>"no-cache, must-revalidate",
     "location"=>"http://www.simplyhired.com/job/ep7zlwnw5b",
     "p3p"=>"CP=\"CAO DSP COR CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT\""},
   status=301>,
 @on_complete_callbacks=[]>

However, when I specify middleware, the body comes as nil.

 conn2 = Faraday.new { |c| c.use FaradayMiddleware::FollowRedirects }
 conn2.get url
=> #<Faraday::Connection:0x00000002ae6fd0
 @builder=#<Faraday::RackBuilder:0x00000002ae6be8 @handlers=[FaradayMiddleware::FollowRedirects]>,
 @default_parallel_manager=nil,
 @headers={"User-Agent"=>"Faraday v0.9.0"},
 @options=#<struct Faraday::RequestOptions params_encoder=nil, proxy=nil, bind=nil, timeout=nil, open_timeout=nil, boundary=nil, oauth=nil>,
 @parallel_manager=nil,
 @params={},
 @proxy=nil,
 @ssl=#<struct Faraday::SSLOptions verify=nil, ca_file=nil, ca_path=nil, verify_mode=nil, cert_store=nil, client_cert=nil, client_key=nil, certificate=nil, private_key=nil, verify_depth=nil, version=nil>,
 @url_prefix=#<URI::HTTP:0x00000002ae6968 URL:http:/>>
[20] pry(main)> conn.get url
=> #<Faraday::Response:0x00000002b575c8
 @env=
  #<struct Faraday::Env
   method=:get,
   body=nil,
   url=#<URI::HTTP:0x00000002b57988 URL:http://www.simplyhired.com/job-id/ep7zlwnw5b/director-of-jobs/>,
   request=#<struct Faraday::RequestOptions params_encoder=nil, proxy=nil, bind=nil, timeout=nil, open_timeout=nil, boundary=nil, oauth=nil>,
   request_headers={"User-Agent"=>"Faraday v0.9.0"},
   ssl=#<struct Faraday::SSLOptions verify=nil, ca_file=nil, ca_path=nil, verify_mode=nil, cert_store=nil, client_cert=nil, client_key=nil, certificate=nil, private_key=nil, verify_depth=nil, version=nil>,
   parallel_manager=nil,
   params=nil,
   response=nil,
   response_headers=nil,
   status=nil>,
 @on_complete_callbacks=[]>

As a matter of fact, every body returns as nil.

 conn.get 'https://github.com'
=> #<Faraday::Response:0x00000002b02910
 @env=
  #<struct Faraday::Env
   method=:get,
   body=nil,
   url=#<URI::HTTPS:0x00000002b02d48 URL:https://github.com>,
   request=#<struct Faraday::RequestOptions params_encoder=nil, proxy=nil, bind=nil, timeout=nil, open_timeout=nil, boundary=nil, oauth=nil>,
   request_headers={"User-Agent"=>"Faraday v0.9.0"},
   ssl=#<struct Faraday::SSLOptions verify=nil, ca_file=nil, ca_path=nil, verify_mode=nil, cert_store=nil, client_cert=nil, client_key=nil, certificate=nil, private_key=nil, verify_depth=nil, version=nil>,
   parallel_manager=nil,
   params=nil,
   response=nil,
   response_headers=nil,
   status=nil>,
 @on_complete_callbacks=[]>

#cache_key in FaradayMiddleware::Caching (https://github.com/lostisland/faraday_middleware/blob/master/lib/faraday_middleware/response/caching.rb#L61) can generate cache keys that are too long for complex URLs.

This can lead to errors like Errno::ENAMETOOLONG: File name too long @ rb_sysopen.

I'm not really sure how best to go about fixing this, as obviously the uniqueness is important as it makes the cache per-identical request. Perhaps we could hash the keys in some way to get them to a uniform, shorter length?

I need to allow caching only if status code of response is 200 and it doesn't got any errors.
Is there a way to manage this in a block or something?

Currently, FollowRedirects will try to parse the body of 3xx responses with the requested Accepts type, rather than the intermediary Content-Type of the redirect response. This can cause it to blow up when, for example, a JSON API request issues a redirect with an HTML body as noted in rails/rails#17194.

We could either prevent it from actually doing the parsing on redirects (bad idea? possible with the way the middleware stack works?) or make it honor the intermediary Content-Type when parsing the body.

Hello,

I've been trying to use FaradayMiddleware::Rashify but it hasn't been working so far.

This is my configuration code:

require 'hashie'
require 'rash'
require 'faraday'
require 'faraday_middleware'
require 'faraday_middleware/response/rashify'

@conn = Faraday.new(@base_uri) do |f|
  f.request  :url_encoded
  f.response :logger

  f.use FaradayMiddleware::Rashify

  f.headers['Content-Type'] = 'application/json'
  f.headers['X-Authenticator-Session'] = @session_key
  f.headers['Accept'] = 'application/json'

  f.adapter Faraday.default_adapter
end

And I also tried with f.use :rashify which didn't work either.

When I debug it, I see that response.body is a String, when it shouldn't.

response = @conn.put(@base_uri + entity.path, body: entity.to_param, headers: headers)

[1] pry(#<API::Client>)> response.body
=> "{\"Status\":\"OK\",\"Content\":{\"RecordingId\":\"5316abab-614c-32a6-b33b-2cca737a3c24\"}}"

I would like to get an object Hashie::Rash so that I can use response.body.content

I am seeing this within my test environment. I am also using fakeweb to stub the API requests, like this:

{"Status":"OK","Content":{"RecordingId":"5316abab-614c-32a6-b33b-2cca737a3c24"}}

Any ideas, @mislav?

Thanks!

trying in a bigger mix, but this is how I was abble to reproduce (irb):

jruby-1.7.13 :001 > settings = {"consumer_key"=>"cdbBByWphpeHKEPfufA3g", "consumer_secret"=>"F4ysW5OMGShQQdniX3pnYHMrCT1QXDv8zKGn8XX7bHI"}
 => {"consumer_key"=>"cdbBByWphpeHKEPfufA3g", "consumer_secret"=>"F4ysW5OMGShQQdniX3pnYHMrCT1QXDv8zKGn8XX7bHI"}
jruby-1.7.13 :002 > require 'simple_oauth'
 => true
jruby-1.7.13 :003 > require 'faraday'
 => true
jruby-1.7.13 :004 > require 'faraday_middleware'
 => true
jruby-1.7.13 :005 > x = FaradayMiddleware::OAuth.new(Proc.new(){|e|e}, settings)
 => #<FaradayMiddleware::OAuth:0x1704f67f @app=#<Proc:0xe4d2696@(irb):5>, @options={"consumer_key"=>"cdbBByWphpeHKEPfufA3g", "consumer_secret"=>"F4ysW5OMGShQQdniX3pnYHMrCT1QXDv8zKGn8XX7bHI"}>
jruby-1.7.13 :006 > x.call({request:{}, request_headers: {}, url: 'https://api.twitter.com/oauth/authorize'})
 => {:request=>{}, :request_headers=>{"Authorization"=>"OAuth oauth_nonce=\"6d0f1c3fa4a0476348f80fbb370d2888\", oauth_signature=\"kjCarOhVC7KLBU9lsXzVLDlryTM%3D\", oauth_signature_method=\"HMAC-SHA1\", oauth_timestamp=\"1410735255\", oauth_version=\"1.0\""}, :url=>"https://api.twitter.com/oauth/authorize"}

am I doing something wrong or it's jruby related bug?

Turns out that fixing the env problem in issue #27 has uncovered another issue. ParseJson and RackCompatible don't seem to play nicely together. It appears as though Rack-Cache is trying to save the parsed hash rather than the json string, which raises an error when rack-cache tries to store it, so it just always results in a cache miss.

The way I expected it to happen was that the ParseJson middleware would only parse once Rack::Cache had completely finished doing its thing. Can RackCompatible and ParseJson work together in that way?

Uploaded a test case for it here:

therabidbanana@ec81555

When updating faraday to 0.9.0 from 0.8.9 I see

Removing outdated .gem files from vendor/cache
faraday_middleware-0.9.0.gem

Then when trying to run "rails s" I get the error.

/Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:251:in `require': cannot load such file -- faraday_middleware (LoadError)
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:251:in `block in require'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:236:in `load_dependency'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:251:in `require'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/balanced-0.2.0/lib/balanced/client.rb:3:in `<top (required)>'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/balanced-0.2.0/lib/balanced.rb:27:in `configure'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/balanced-0.2.0/lib/balanced.rb:80:in `<module:Balanced>'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/balanced-0.2.0/lib/balanced.rb:4:in `<top (required)>'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353@global/gems/bundler-1.3.5/lib/bundler/runtime.rb:72:in `require'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353@global/gems/bundler-1.3.5/lib/bundler/runtime.rb:72:in `block (2 levels) in require'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353@global/gems/bundler-1.3.5/lib/bundler/runtime.rb:70:in `each'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353@global/gems/bundler-1.3.5/lib/bundler/runtime.rb:70:in `block in require'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353@global/gems/bundler-1.3.5/lib/bundler/runtime.rb:59:in `each'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353@global/gems/bundler-1.3.5/lib/bundler/runtime.rb:59:in `require'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353@global/gems/bundler-1.3.5/lib/bundler.rb:132:in `require'
    from /Users/rever/Documents/project/project_folder/config/application.rb:7:in `<top (required)>'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/railties-3.2.13/lib/rails/commands.rb:53:in `require'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/railties-3.2.13/lib/rails/commands.rb:53:in `block in <top (required)>'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/railties-3.2.13/lib/rails/commands.rb:50:in `tap'
    from /Users/rever/.rvm/gems/ruby-2.0.0-p353/gems/railties-3.2.13/lib/rails/commands.rb:50:in `<top (required)>'
    from script/rails:6:in `require'
    from script/rails:6:in `<main>'

I'm not sure if I am correct in posting the issue here but wasn't sure where else to start.

While looking for this. I've found faraday-cache_redis-store but It seems to be a bit old, is there a native way to do this in faraday_middleware at the moment?

The docs only explain for memcached.

I followed the example essentially verbatim: https://github.com/lostisland/faraday_middleware/wiki/Instrumentation

The start_time / end_time that were coming out were telling me that my requests were taking a fraction of a millisecond, and I know they should be in the hundreds of milliseconds.

I know it is incorrect b/c I put this dumb check in:

start = Time.now
response = @conn.run_request(method, nil, nil, nil) do |req|
  #do all the stuff to build the request
end
endd = Time.now
puts "it took #{((endd - start)*1000).to_i} ms"

And that reports "it took 921 ms" for some request (which is within my expectations).

For the same request, the ActiveSupport::Notifications message, as shown in the wiki, reports:
start: 1385151531.203627
end: 1385151531.203826
duration: 0.19884109497070312 ms

So I noticed that the middleware for instrumentation is simply:

    def call(env)
      ActiveSupport::Notifications.instrument(@name, env) do
        @app.call(env)
      end
    end

I began to suspect that perhaps that is not waiting for the request to complete.

I tried stuff like the following, but that doesn't seem to change the end_time I get. I have no idea why?

    def call(env)
      ActiveSupport::Notifications.instrument(@name, env) do
        response = @app.call(env)
        until response.finished?
          Log.debug "NOT DONE"
          sleep 0.1
        end
        response
      end
    end

Can anyone help me understand what is going on? I am happy to submit a pull request if I can figure out how to fix this.

Now that I have server rack-cache and faraday rack-cache working together, I've found another issue: nothing expires from the cache. I'm having trouble narrowing in on the exact error - but it seems related to the faraday :net_http adapter. First I was getting a NoMethodError due to nil values in env[:request_headers], then, with a fix for that in rack_compatible, I get caching that refuses to expire.

Test case:

therabidbanana@621d929

Changing to :em_http has allowed me to work around the problem, but I can't hunt down the exact reason why.

Consider the following code slightly adapted from the readme:

connection = Faraday.new 'http://example.com/api' do |conn|
  conn.use FaradayMiddleware::FollowRedirects, limit: 5
  conn.adapter Faraday.default_adapter
end

Every request will follow redirects based on the configuration above.

Let's say that i want

connection.get '/paradise'

To follow any redirects

But

connection.get '/hell'

To not follow any redirects, and maybe log the redirection attempt.

Is this possible?

In faraday_example.rb:
require 'rubygems'
require 'faraday'
require 'faraday_middleware'

conn = Faraday::Connection.new(:url => 'http://api.twitter.com/1') do |builder|
  builder.adapter Faraday.default_adapter
  builder.use Faraday::Response::MultiJson
end

resp = conn.get do |req|
  req.url '/users/show.json', :screen_name => 'pengwynn'
end

u = resp.body
puts u['name']

Testing it out:
$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
$ ruby faraday_example.rb
Wynn Netherland
$ rvm use 1.9.2
Using /home/jason/.rvm/gems/ruby-1.9.2-p0
$ ruby faraday_example.rb

faraday_example.rb:7: warning: toplevel constant MultiJson referenced by Faraday::Response::MultiJson
/home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/builder.rb:55:in `block in use': undefined method `new' for MultiJson:Module (NoMethodError)
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/builder.rb:51:in `call'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/builder.rb:51:in `block in to_app'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/builder.rb:51:in `each'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/builder.rb:51:in `inject'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/builder.rb:51:in `to_app'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/connection.rb:161:in `to_app'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/request.rb:82:in `run'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/request.rb:26:in `run'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/connection.rb:169:in `run_request'
    from /home/jason/.rvm/gems/ruby-1.9.2-p0/gems/faraday-0.5.2/lib/faraday/connection.rb:64:in `get'
    from faraday_example.rb:10:in `'

Hi!
I'm using FaradayMiddleware::FollowRedirects, I'm doing a GET to a URL which results in the server returning 302 response with a Location header that looks like the following:

https://host.example.com/some/path#someanchor

In this method the URL in the location header gets (IMO, incorrectly) encoded to the following:

https://host.example.com/some/path%23someanchor

Resulting in a 404 response whet the redirection is followed.

(note: browsers don't have this behavior, they don't encode # and the correct URI is requested)

If you agree I can create a PR adding the # char to the URI_UNSAFE regex so it doesn't get encoded.

(This is on FaradayMiddleware 0.10.0, with mri ruby 2.2.3)

Thanks for this great library.

Seba.

require 'octokit.rb'

client = Octokit::Client.new(:login => "me", :password => "sekret")
client.follow("sferik")

ruby-1.9.3_p194

/home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/middleware.rb:20:in new': missing dependency for FaradayMiddleware::EncodeJson: no such file to load -- json (RuntimeError) from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/builder.rb:43:inbuild'
from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/builder.rb:78:in to_app' from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/connection.rb:106:ininject'
from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/builder.rb:78:in each' from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/builder.rb:78:ininject'
from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/builder.rb:78:in to_app' from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/connection.rb:74:inapp'
from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/connection.rb:226:in run_request' from /home/ralf/.gem/ruby/1.8/gems/faraday-0.8.4/lib/faraday/connection.rb:99:input'
from /home/ralf/.gem/ruby/1.8/gems/octokit-1.15.1/lib/octokit/request.rb:41:in send' from /home/ralf/.gem/ruby/1.8/gems/octokit-1.15.1/lib/octokit/request.rb:41:inrequest'

Please publish v0.8.7 to rubygems.

$ pry
[1] pry(main)> RUBY_VERSION
=> "2.2.3"
[2] pry(main)> require "faraday"
=> true
[3] pry(main)> require "faraday_middleware"
=> true
[4] pry(main)> require "excon"
=> true
[5] pry(main)> Faraday::VERSION
=> "0.9.2"
[6] pry(main)> require "faraday_middleware/version"
=> true
[7] pry(main)> FaradayMiddleware::VERSION
=> "0.10.0"
[8] pry(main)> Excon::VERSION
=> "0.45.4"
[9] pry(main)> connection = Faraday.new do |faraday|
[9] pry(main)*   faraday.use FaradayMiddleware::FollowRedirects
[9] pry(main)*   faraday.adapter :excon
[9] pry(main)* end
=> #<Faraday::Connection:0x007fb053377908
 @builder=#<Faraday::RackBuilder:0x007fb053377520 @handlers=[FaradayMiddleware::FollowRedirects, Faraday::Adapter::Excon]>,
 @default_parallel_manager=nil,
 @headers={"User-Agent"=>"Faraday v0.9.2"},
 @options=#<struct Faraday::RequestOptions params_encoder=nil, proxy=nil, bind=nil, timeout=nil, open_timeout=nil, boundary=nil, oauth=nil>,
 @parallel_manager=nil,
 @params={},
 @proxy=nil,
 @ssl=
  #<struct Faraday::SSLOptions
   verify=nil,
   ca_file=nil,
   ca_path=nil,
   verify_mode=nil,
   cert_store=nil,
   client_cert=nil,
   client_key=nil,
   certificate=nil,
   private_key=nil,
   verify_depth=nil,
   version=nil>,
 @url_prefix=#<URI::HTTP http:/>>

[10] pry(main)> connection.head("http://www.notiflux.com")
TypeError: no implicit conversion of nil into String
from /Users/dentarg/.gem/ruby/2.2.3/gems/excon-0.45.4/lib/excon/connection.rb:89:in `initialize'

[11] pry(main)> wtf??
Exception: TypeError: no implicit conversion of nil into String
--
 0: /Users/dentarg/.gem/ruby/2.2.3/gems/excon-0.45.4/lib/excon/connection.rb:89:in `initialize'
 1: /Users/dentarg/.gem/ruby/2.2.3/gems/excon-0.45.4/lib/excon.rb:126:in `new'
 2: /Users/dentarg/.gem/ruby/2.2.3/gems/excon-0.45.4/lib/excon.rb:126:in `new'
 3: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday-0.9.2/lib/faraday/adapter/excon.rb:53:in `call'
 4: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday_middleware-0.10.0/lib/faraday_middleware/response/follow_redirects.rb:76:in `perform_with_redirection'
 5: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday_middleware-0.10.0/lib/faraday_middleware/response/follow_redirects.rb:82:in `block in perform_with_redirection'
 6: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday-0.9.2/lib/faraday/response.rb:57:in `on_complete'
 7: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday_middleware-0.10.0/lib/faraday_middleware/response/follow_redirects.rb:78:in `perform_with_redirection'
 8: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday_middleware-0.10.0/lib/faraday_middleware/response/follow_redirects.rb:64:in `call'
 9: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday-0.9.2/lib/faraday/rack_builder.rb:139:in `build_response'
10: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday-0.9.2/lib/faraday/connection.rb:377:in `run_request'
11: /Users/dentarg/.gem/ruby/2.2.3/gems/faraday-0.9.2/lib/faraday/connection.rb:140:in `head'
12: (pry):13:in `__pry__'
13: /Users/dentarg/.gem/ruby/2.2.3/gems/pry-0.10.3/lib/pry/pry_instance.rb:355:in `eval'
14: /Users/dentarg/.gem/ruby/2.2.3/gems/pry-0.10.3/lib/pry/pry_instance.rb:355:in `evaluate_ruby'
15: /Users/dentarg/.gem/ruby/2.2.3/gems/pry-0.10.3/lib/pry/pry_instance.rb:323:in `handle_line'
16: /Users/dentarg/.gem/ruby/2.2.3/gems/pry-0.10.3/lib/pry/pry_instance.rb:243:in `block (2 levels) in eval'
17: /Users/dentarg/.gem/ruby/2.2.3/gems/pry-0.10.3/lib/pry/pry_instance.rb:242:in `catch'
18: /Users/dentarg/.gem/ruby/2.2.3/gems/pry-0.10.3/lib/pry/pry_instance.rb:242:in `block in eval'
19: /Users/dentarg/.gem/ruby/2.2.3/gems/pry-0.10.3/lib/pry/pry_instance.rb:241:in `catch'

Using Excon directly I get another exception (better, specific to Excon):

[12] pry(main)> excon_connection = Excon.new("http://www.notiflux.com", middlewares: Excon.defaults[:middlewares] + [Excon::Middleware::RedirectFollower])
=> #<Excon::Connection:7fb053534f98 @data={:chunk_size=>1048576, :ciphers=>"HIGH:!SSLv2:!aNULL:!eNULL:!3DES", :connect_timeout=>60, :debug_request=>false, :debug_response=>false, :headers=>{"User-Agent"=>"excon/0.45.4"}, :idempotent=>false, :instrumentor_name=>"excon", :middlewares=>[Excon::Middleware::ResponseParser, Excon::Middleware::Expects, Excon::Middleware::Idempotent, Excon::Middleware::Instrumentor, Excon::Middleware::Mock, Excon::Middleware::RedirectFollower], :mock=>false, :nonblock=>true, :omit_default_port=>false, :persistent=>false, :read_timeout=>60, :retry_limit=>4, :ssl_verify_peer=>true, :tcp_nodelay=>false, :thread_safe_sockets=>true, :uri_parser=>URI, :versions=>"excon/0.45.4 (x86_64-darwin14) ruby/2.2.3", :write_timeout=>60, :host=>"www.notiflux.com", :hostname=>"www.notiflux.com", :path=>"", :port=>80, :query=>nil, :scheme=>"http"} @socket_key="http://www.notiflux.com:80">
[13] pry(main)> excon_connection.head
Excon::Errors::SocketError: hostname "www.notiflux.com" does not match the server certificate (OpenSSL::SSL::SSLError) (Excon::Errors::SocketError)
from /Users/dentarg/.rubies/ruby-2.2.3/lib/ruby/2.2.0/openssl/ssl.rb:240:in `post_connection_check'

Yes, http://www.notiflux.com is obviously broken, it responds with Location: https://, but I think we should be able to handle broken sites.

$ curl -s -v -L  -o /dev/null http://www.notiflux.com
* Rebuilt URL to: http://www.notiflux.com/
*   Trying 104.130.212.218...
* Connected to www.notiflux.com (104.130.212.218) port 80 (#0)
> GET / HTTP/1.1
> Host: www.notiflux.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://
< Server: Microsoft-IIS/8.5
< X-Powered-By: ASP.NET
< Date: Tue, 16 Feb 2016 10:12:58 GMT
< Content-Length: 0
<
* Connection #0 to host www.notiflux.com left intact
* Issue another request to this URL: 'http://www.notiflux.com/https://'
* Found bundle for host www.notiflux.com: 0x7ffb8ac09d80
* Re-using existing connection! (#0) with host www.notiflux.com
* Connected to www.notiflux.com (104.130.212.218) port 80 (#0)
> GET /https:// HTTP/1.1
> Host: www.notiflux.com
> User-Agent: curl/7.43.0
> Accept: */*

...

Interestingly, curl treats the value from the Location header as relative. But that's another issue I guess... :)

I'd like to use the OJ gem for my faraday JSON needs. I currently have to steal the parse and encode middlewares and change two lines in each file.

It seems like everyone would benefit if we replaced calls to JSON with calls to MultiJson. I'm happy to make the required changes, but I wanted to see what the consensus was before I bothered (seems fairly trivial, so perhaps this discussion has already been had?).

I'm not sure if this is an with the order of my middleware, or something I don't understand about OAuth2, but as soon as I add OAuth2 to the stack, all subsequent requests are misses. Removing OAuth2 means subsequent requests are "fresh".

Here's a cut-down stack that seems to work from a cache perspective:

        c.use Faraday::Response::Logger
        c.use FaradayMiddleware::RackCompatible, Rack::Cache::Context,
         :metastore   => "memcached://localhost:11211/meta",
         :entitystore => "memcached://localhost:11211/body",
         :ignore_headers => %w[Set-Cookie X-Content-Digest]
        c.use Faraday::Adapter::NetHttp

And here's one that seems to fail (I see a new HTTP request to the API) once I add-in OAuth2:

        c.use FaradayMiddleware::OAuth2, @token
        c.use Faraday::Response::Logger
        c.use FaradayMiddleware::RackCompatible, Rack::Cache::Context,
         :metastore   => "memcached://localhost:11211/meta",
         :entitystore => "memcached://localhost:11211/body",
         :ignore_headers => %w[Set-Cookie X-Content-Digest]
        c.use Faraday::Adapter::NetHttp

Where's the right place in the stack for OAuth2? What am I missing?

Hello,

I created an RSS response middleware that uses RSS::Parser to unobtrusively parse RSS feeds. I was wondering if there was any interest in adding it to faraday_middleware? If so I'll open a pull request. If not, no big deal!

Thanks

I was fighting with the setting for couple of mins and I noticed the only way the multipart work is putting on the top of the settings, is ok that behavior?. I'm using ruby 2.0.0

This way works:

Faraday.new(:url => api_url) do |faraday|
        faraday.request :multipart
         faraday.request  :oauth2, token
end

Didn't works for me 😄

Faraday.new(:url => api_url) do |faraday|
        faraday.request :multipart
         faraday.request  :oauth2, token
end

Thoughts on this? It's not currently possible.

I'm primarily thinking about symbolize_names.

Hashie::Rash has been part of Hashie since 2.1.0. I think faraday_middleware needs to be updated to that and remove the dependency on the rash gem.

Hi guys,

One or our customers is using Angular.js on their website and we are using Faraday to crawl it. The problem is that we are getting an infinitive loop when we try to resolve/follow their URLs, resulting in FaradayMiddleware::RedirectLimitReached: too many redirects; last one to: ..

Here are the steps:

• GET http://www.gleamworld.com/looks/311723
• Web Server checks for #! because it's not there returns a 301 (Redirect) with http://www.gleamworld.com/#!/looks/311723
• Faraday follows the redirect but escapes the URL with http://www.gleamworld.com/%23!/looks/311723
• Web Server checks for #! because it's not there returns a 301 (Redirect) with http://www.gleamworld.com/#!/%23!/looks/311723
• Faraday follows the redirect but escapes the URL with http://www.gleamworld.com/%23!/%23!/looks/311723
• ....

Angular uses # for navigation purposes. The ! it's because they are using this specification from Google https://developers.google.com/webmasters/ajax-crawling/docs/specification.

The problem is in this function https://github.com/lostisland/faraday_middleware/blob/master/lib/faraday_middleware/response/follow_redirects.rb#L120

I will like to have your feedback to understand if this is a problem on the library or on the website. My believe is that Faraday should not escape the # because it's not in the URI_UNSAFE reg exp. Also, their links work with the browser.

The title pretty much sums it up, as far as I understand oj is much faster than stdlib json implementation. Some option to be able to swap json parse would be nice I think.

I want debug it, but not found output origin raw body.

Found an error while creating a cache for API client. Not sure if its due to improper usage or just a bug:

/Users/sosedoff/.rvm/gems/ruby-1.9.2-p290/gems/faraday_middleware-0.8.4/lib/faraday_middleware/response/caching.rb:74:in `finalize_response': undefined method `env' for nil:NilClass (NoMethodError)
    from /Users/sosedoff/.rvm/gems/ruby-1.9.2-p290/gems/faraday_middleware-0.8.4/lib/faraday_middleware/response/caching.rb:38:in `call'
    from /Users/sosedoff/.rvm/gems/ruby-1.9.2-p290/gems/faraday-0.7.6/lib/faraday/connection.rb:210:in `run_request'
    from /Users/sosedoff/.rvm/gems/ruby-1.9.2-p290/gems/faraday-0.7.6/lib/faraday/connection.rb:93:in `get'

Usage:

module TestApp
  module Cache
    def self.fetch(key)
      nil
    end

    def self.read(key)
      nil
    end

    def self.write(key, value)
      puts "#{key} => #{value}"
    end
  end
end

def connection(url)
  connection = Faraday.new(url) do |c|
    c.use(Faraday::Request::Multipart)
    c.use(Faraday::Request::UrlEncoded)
    c.use(Faraday::Response::ParseJson)
    c.use(FaradayMiddleware::Caching, TestApp::Cache, :ignore_params => [:api_token])
    c.use(Faraday::Response::Logger)
    c.adapter(Faraday.default_adapter)
  end
end

Any idea why this is happening ?

Hi,

I've put together very simple timing middleware for Faraday. If you think it will be good to have it here I'm happy to port it and open pull request :)

I was encountering an issue trying to wrap Rack::Cache::Context with RackCompatible - turns out that the ParseJson middleware was calling fetch on env[:request], but the RackCompatible middleware was somehow dropping that field. I monkey-patched it like so:

class ParseJson < ResponseMiddleware
  def preserve_raw?(env)
     env[:request] ||= {}
     env[:request].fetch(:preserve_raw, @options[:preserve_raw])
  end
end

but obviously that's not ideal. I realize the RackCompatible class is probably still experimental , would a better approach be to use the Cache middleware and write a custom cache that looks at HTTP headers, rather than trying to hack Rack-Cache into a faraday stack? Or am I just using it wrong?

My faraday stack looks like this:

@connection = Faraday.new('http://localhost:9292/') do |b|
  b.request :basic_auth, 'foo', 'bar'
  b.use FaradayMiddleware::Mashify
  b.use FaradayMiddleware::ParseJson
  b.use FaradayMiddleware::EncodeJson
  b.response :raise_error
  b.use FaradayMiddleware::FollowRedirects
  b.use FaradayMiddleware::RackCompatible, Rack::Cache::Context, 
    :verbose => true,
    :private_headers => []
  b.adapter Faraday.default_adapter
end

Hello,

Can you please update your gem on rubygems to use the latest features?

Ty.

I could really use the current master version of the follow redirects middleware ( with the code that escapes the characters in redirect urls ). Is there any possibility you could do a small release? Thanks!

The deflate encoding seems to refer to one of the following formats depending on the implementation:

• "DEFLATE": a zlib stream containing a raw deflate stream (This is what RFC defines)
• "deflate": a raw deflate stream

cf. https://en.wikipedia.org/wiki/HTTP_compression#Problems_preventing_the_use_of_HTTP_compression

So, there's a compatibility problem here. Microsoft servers and Rack::Deflate adopt the latter, while there are servers that adopt the former including Apache's mod_deflate.
Major browsers (i.e. clients) support both, so this problem may be rather unknown.

FaradayMiddleware::Gzip currently is only aware of DEFLATE, so if it receives a raw deflate stream it will fail with "incorrect header check" (Zlib::DataError).

I think the middleware could implement a fallback as follows, as well as dropping deflate from the default Accept-Encoding request header value for safety.

    def inflate(body)
      # Inflate as a DEFLATE (RFC 1950+RFC 1951) stream
      Zlib::Inflate.inflate(body)
    rescue Zlib::DataError
      begin
        # Fall back to inflating as a "raw" deflate stream which
        # Microsoft servers return
        inflate = Zlib::Inflate.new(-Zlib::MAX_WBITS)
        inflate.inflate(body)
      ensure
        inflate.close
      end
    end

What do you guys think? I'd be happy to make a PR, but just wanted to make sure to share the problem before that.

Hey guys,

I hate to say this but the wiki is slightly confusing; at least to me. In 'Changes 0.8' it is said that all the parsing stuff are under 'FaradayMiddleware. Yet in 'Parsing responses', there is an updated examples labeled 'in Faraday 0.8 or above'. The result is that this is all misleading, and there is no working example of how to parse responses properly under Faraday 0.8.

---------------------faraday_middleware/wiki/Changes-0.8---------------------------------
When upgrading from v0.7, the v0.8 should be backwards-compatible for the most part.

All middleware names have changed. Previously they were nested in the Faraday namespace, such as "Faraday::Response::*". Now they are all under FaradayMiddleware namespace, e.g. FaradayMiddleware::ParseJson.

--------/faraday_middleware/wiki/Parsing-responses---------------------

in Faraday 0.8 or above:

connection = Faraday.new 'http://example.com/api' do |conn|
conn.response :xml, :content_type => /\bxml$/
conn.response :json, :content_type => /\bjson$/

conn.adapter Faraday.default_adapter
end

the above raises the following error every time ":json is not registered on Faraday::Response"

I noticed there are FIXME notes to properly implement 307 and 302 redirection in the follow redirects middleware. I was curious to see exactly what the "proper" implementation of a 302 included. So, according to RFC 2616:

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

This MUST NOT verbiage appears to apply to 301, 302, and 307. Since Faraday is mostly used in non-interactive sessions, I'm wondering if you're okay with dropping the user confirmation portion of the specification? And, in that case, I guess both HTTP 302 and 307 should repeat the original request (including method and data). Whereas with the 301 and 303 responses it would force the original request to become a GET request to the returned Location URI.

Below is my understanding of "proper" HTTP/1.1 redirection:

HTTP 301: For GET/PUT/POST/DELETE requests, always redirect with GET to the Location. (cacheable)
HTTP 302: For GET/PUT/POST/DELETE requests, replay the same method/data request to the Location. (conditionally cacheable)
HTTP 303: For GET/PUT/POST/DELETE requests, always redirect with GET to the Location. (not cacheable)
HTTP 307: For GET/PUT/POST/DELETE requests, replay the same method/data request to the Location. (conditionally cacheable)

Im having an issue with middleware triggering in certain situation.

The API i'm consuming has JSON and XML interfaces. I use JSON, but when the request fails it renders the failed response in XML format and returns status other than 200 (406 for example) which should be handled by custom error middleware first.

But for some reason the stack continues and when it reaches the ParseJson middleware it throws a decoding exception (in my case MultiJson::DecodeError).

Whats the best workaround for this kind of behavior?

Here is the code that i use:

def connection(url)
  connection = Faraday.new(url) do |c|
    c.use(Faraday::Request::UrlEncoded)
    c.use(Faraday::Response::RaiseApiError)
    c.use(Faraday::Response::ParseJson)
    c.adapter(Faraday.default_adapter)
  end
end

Error handling middleware:

require 'faraday_middleware'

module Faraday
  class Response::RaiseApiError < Response::Middleware
    def on_complete(response)
      case response[:status].to_i
        when 400 then raise API::BadRequest
        when 401 then raise API::Unauthorized
        when 403 then raise API::Forbidden
        when 404 then raise API::NotFound
        when 406 then raise API::BadRequest
        when 413 then raise API::OverLimit
        when 501 then raise API::NotImplemented
        when 502 then raise API::BadGateway
        when 503 then raise API::ServiceUnavailable
      end
    end
  end
end

Something like FaradayMiddleware::HashieExtensions that would allow us to compose things like Hashie::Extensions::MethodAccess and similar on-demand, and not default to using Hashie::Mash or Hashie::Rash.

...or I am unable to comprehend how to make it work :). It's been one of those weekends, so I might be Doin' It Wrong (TM), but I don't think so.

So, here's a transcript from a test against http://httpstat.us/302. You can see in the basic Faraday.get example that the response is an ordinary HTTP 302 with a location header. All good.

1.9.3p125 :005 > Faraday.get("http://httpstat.us/302")
 => #<Faraday::Response:0x000001013bf860 @env={:method=>:get, :body=>"302 Found\r\n\r\nLocation: http://httpstat.us", :url=>#<Addressable::URI:0x809d77d8 URI:http://httpstat.us/302>, :request_headers=>{}, :parallel_manager=>nil, :request=>{:proxy=>nil}, :ssl=>{}, :status=>302, :response_headers=>{"server"=>"nginx", "date"=>"Sun, 01 Apr 2012 22:20:36 GMT", "content-type"=>"text/plain", "connection"=>"close", "location"=>"http://httpstat.us", "access-control-allow-origin"=>"*", "content-length"=>"41", "x-varnish"=>"1462090777", "age"=>"0", "via"=>"1.1 varnish"}, :response=>#<Faraday::Response:0x000001013bf860 ...>}, @on_complete_callbacks=[]> 

However, if I construct a Faraday connection with the FaradayMiddleware::FollowRedirects middleware mounted, the response is not what I would expect:

1.9.3p125 :003 > conn = Faraday.new("http://httpstat.us/302") { |b| b.use FaradayMiddleware::FollowRedirects }
 => #<Faraday::Connection:0x00000100cd0270 @headers={}, @params={}, @options={}, @ssl={}, @parallel_manager=nil, @scheme="http", @port=nil, @host="httpstat.us", @path_prefix="/302", @proxy=nil, @builder=#<Faraday::Builder:0x00000100ccfb90 @handlers=[FaradayMiddleware::FollowRedirects]>> 
1.9.3p125 :004 > conn.get("/")
 => #<Faraday::Response:0x00000100cdb350 @env={:method=>:get, :body=>nil, :url=>#<Addressable::URI:0x8066dc14 URI:http://httpstat.us/>, :request_headers=>{}, :parallel_manager=>nil, :request=>{:proxy=>nil}, :ssl=>{}, :response=>#<Faraday::Response:0x00000100cdb350 ...>}, @on_complete_callbacks=[]> 

Note both body and status are nil. My read is that somehow the request isn't finished, but some exploration of the middleware's source code didn't reveal a whole lot to me. My apologies for the bug report without a pull request, but I'm still new to Faraday :). Let me know if I can provide any additional information.

Thanks!

Hi.
I've noticed that access_token is showable when using OAuth2 middleware like...

require 'faraday'
require 'faraday_middleware'

conn = Faraday.new(url: "https://example.com") do |builder|
  builder.request :oauth2, 'access_token'
end

conn.get
#=> access to https://example.com/?access_token=access_token

The code is here.
https://github.com/lostisland/faraday_middleware/blob/master/lib/faraday_middleware/request/oauth2.rb#L37

This behavior looks like not secure for me. (Of course I know this is one of the popular usage.)
So I think adding access_token to url parameter should be optional.
How do you think this?

Sorry for my poor English 🍶
Regards.

I have encountered a scenario where I need to call an external API to get images and pdfs and parse them to corresponding filetypes before sending to the user. I could not found any of such parser in Faraday. Is it a good idea to add it? Or is it better do the keep these separate?

This doesn't appear to be correct behavior when encountering an HTTP error response and throws an exception: Faraday::Error::ParsingError: 757.

Is this correct behavior? Is there an option to only have json parse 2xx OK responses?

I, [2013-10-03T17:23:33.525257 #7138] INFO -- : post https://www.google.com/cloudprint/list
D, [2013-10-03T17:23:33.525361 #7138] DEBUG -- request: User-Agent: "Faraday v0.8.8"
Authorization: "Bearer ya29.AHES6ZR1VCYkSkKo_Xlvc5fLcblzzerPeG_v-OajvosYLLo"
Content-Type: "application/x-www-form-urlencoded"
I, [2013-10-03T17:23:34.040856 #7138] INFO -- Status: 403
D, [2013-10-03T17:23:34.041036 #7138] DEBUG -- response: content-type: "text/html; charset=utf-8"
cache-control: "no-cache, no-store, max-age=0, must-revalidate"
pragma: "no-cache"
expires: "Fri, 01 Jan 1990 00:00:00 GMT"
date: "Fri, 04 Oct 2013 00:23:33 GMT"
:
Faraday::Error::ParsingError: 757: unexpected token at '<title>Error 403 (Forbidden)!!1</title><style>*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAKsAAADVCAMAAAAfHvCaAAAAGFBMVEVYn%2BH%2F%2F%2F%2Bex%2B3U5vd7s%2Bfq8%2Fs0itq72PMLUPvtAAASvklEQVR4AbXBC0JqCQxEwT5Jd7L%2FHc8FdR4g%2BEGtEr8u%2FBH ...

I don't see any significant changes 0.9.2 vs 0.10.0 but using Faraday Middleware Caching with Her and Dalli results in this error on 0.10.0: undefined method 'read' for #<Dalli::Client:0x007f9ba40faef0>. No problems with 0.9.2 (no other changes).

I realize this is more a question than an issue, but as there is no indicated means for the community to communicate with the gem authors, this is where I am posting it.

I am trying to understand the reason why MultiJSON was removed. For a project I am working on with Faraday::Middleware, we would prefer to abstract away the JSON implementation so that it can use the best options available rather than hard-coded to the standard library. Perhaps this could be added to a FAQ section in the Wiki?

Thanks..

• mike

Looks like in a83b39c, the if env[:parallel_manager] condition and the cache_on_complete method it uses were not tested.

The feature itself seems like a bit of a smell — why would the concurrent case not work with threadsafe code?

def initialize

  @conn = Faraday.new(:url => 'https://www.googleapis.com', :params => {:key => @@key}) do |conn|
         conn.request  :url_encoded             # form-encode POST params
     conn.response :logger                  # log requests to STDOUT
     conn.adapter  Faraday.default_adapter  # make requests with Net::HTTP
     conn.request :json
     conn.response :json
     conn.response :caching, :ignore_params => %w[access_token] do  
     ActiveSupport::Cache::FileStore.new File.join(ENV['TMPDIR'] || '/tmp', 'cache'), :namespace => 'googlecustomsearch', :expires_in => 3600  # one hour
        end
    end

end

On this line

results = @conn.get('/customsearch/v1', { :cx => cx, :q => title }).body["items"]

# NoMethodError: undefined method `fetch' for nil:NilClass



**Ruby on Rails 3.2.8**
**Ruby 1.9.3**


    gem "faraday"
    gem "faraday_middleware"

Hello,
I'm currently fighting with a Timeout error when using FollowRedirect middleware on a multipart request responding with 302.

I've isolated the behaviour with the help of a minimal Sinatra app :
https://github.com/etaque/faraday-redirect-bug

Would gladly get some help, any pointer to resolve this ?
Thanks :)

Hi,

I'm just curious what the license for use of these middlewares is. I can't find it in the code.

Thanks!

So I believe that Faraday Middleware is using my gem Rash: https://github.com/tcocca/rash for the Rashify middleware however, somebody filed a ticket with my gem: tcocca/rash#9 as it appears that Hashie has added their own Rash type: https://github.com/intridea/hashie/blob/master/lib/hashie/rash.rb which is clearly not intended to provide the same functionality (https://github.com/intridea/hashie#rash)

Looks like Hashie::Rash first appeared in Hashie v2.1.0

I'm not sure what the best solution is here. I could re-name my gem and extension but there are a lot of gems using it and I believe you are the biggest of those gems in terms of usage so I wanted to get your thoughts on the situation.

I am thinking I ned to release a new minor version for my Rash gem that locks down the hashie dependency to < 2.1.0. Then I will either need to release a new major version of Rash that changes the class name and has a Hashie dependency that is either > 2.1.0 or really no set version. OR I just release a new gem with a new name altogether. I think this is a the best option as it will be the least confusing to people looking to use the gem.

Unfortunately, like a lot of other gems it seems that faraday_middleware is "soft loading" rash and not requiring it in the gemspec. I think this could potentially be a large problem.

Just wanted to get your thoughts/opinions. Also, any ideas for a new name for my version of Rash?

Was troubleshooting a problem with JSON handling, and looking through things, and came across this: https://github.com/lostisland/faraday_middleware/blob/master/lib/faraday_middleware/response/parse_yaml.rb

which IIRC is pretty unsafe. You probably want Psych.safe_load

Hi Team,

Issue while sending PUT & DELETE request to an OAUTH Server. I am trying to update an Scope entity with the guid http://website.com/auth/listings

GEM versions:
faraday (0.8.5)
faraday_middleware (0.9.0)

Below is the request from my code:

put https://login.website.net/oauth/api/Scopes('http://website.com/auth/listings')
delete https://login.website.net/oauth/api/Scopes('http://website.com/auth/listings')

Faraday gem converts the double slash to single slash as below while sending request to OAUTH Server.

put https://login.website.net/oauth/api/Scopes('http:/website.com/auth/listings')
delete https://login.website.net/oauth/api/Scopes('http:/website.com/auth/listings')

Because it converts double slash to single slash, OAUTH server responds back with "entity not found exception"

Can anyone suggest a fix for this?

Thanks,
Mohan