Builder does not maintain order! about faraday HOT 7 CLOSED

Note: The source code for the relevant middleware lives in the faraday_middleware gem: https://github.com/pengwynn/faraday_middleware/tree/master/lib/faraday/response

from faraday.

This is not breakage, it's something I actually fixed in Faraday. From the README:

The order in which middleware is stacked is important. Like with Rack, the first middleware on the list wraps all others, while the last middleware is the innermost one, so that's usually the adapter.

Before my refactoring, Faraday respected this to some extent, but the order in which on_complete handlers fired was a total mess and very inconsistent. Now there's only one rule: request middleware fires in order in which they were added, response middleware fires in the reverse order. Adapters come last in the bottom. This is the standard Rack way.

Your stack should look like:

Faraday.new(options) do |builder|
  builder.request :multipart
  builder.request :url_encoded
  builder.use Faraday::Request::OAuth, authentication if authenticated?
  builder.use Faraday::Response::Mashify unless raw
  unless raw
    case format.to_s.downcase
    when 'json'
      builder.use Faraday::Response::ParseJson
    when 'xml'
      builder.use Faraday::Response::ParseXml
    end
  end
  builder.use Faraday::Response::RaiseHttp4xx
  builder.use Faraday::Response::RaiseHttp5xx
  builder.adapter(adapter)
end

Now XML/JSON will first get parsed, then mashified.

One more note: the bundled Multipart middleware is a little different than the one you removed. The bundled one still doesn't handle "File" instances.

from faraday.

Thanks for explaining. The ordering was confusing me.

Is there a reason why the built-in Multipart middleware doesn't handle "File" instances? Would it make sense to replace the one in faraday with the one in the twitter gem, which handles files correctly?

Or maybe I should add MultipartWithFile middleware to the faraday_middleware gem?

from faraday.

I just ran into another issue where env[:http_headers] used to return {} when it was blank, but now it returns nil. Was this intentional?

from faraday.

I'd welcome that you contribute File handling together with mime-type guessing based on filename.

As for http_headers: you must have confused that with request_headers or response_headers.

from faraday.

Yes, I meant response_headers. Was that an intention move to change the default to nil when they're empty? I needed to make this change to make it work: jnunemaker/twitter@97644a9#diff-1

from faraday.

That's a bug. Is this with the test adapter? Please file an issue.

Luckily, in real world response headers are never empty.

from faraday.