In this order the @env would not be changed by the "on complete"
callbacks, meaning that the response would not change after parallel
requests finish (e.g. JSON would not be parsed).
This would work
def on_complete(env)
env[:body].upcase!
end
But this wouldn't
def on_complete(env)
env[:body] = env[:body].upcase
end
Old behavior:
# init connection with some defaults:
conn = Faraday.new :params => {...}, :request => {...}
conn.get('/') do |request|
request.params = {...} # params got merged with defaults
request.options = {...} # options got deep-merged with defaults
end
New behavior:
conn.get('/', {...}) do |request|
request.params.update(...) # merge with existing params
request.params = {...} # replace all existing params
request.options[:proxy][:user] = "..." # add extra request options:
request.options = {...} # replace all existing options
end
Pros of the new behavior are consistency, ability to completely override
parameters per-request. Cons are breaking backwards-compatibility.
This is a potentially breaking change for 3rd party code that relies on
env[:url] being specifically Addressable. After this change all urls are
passed around as instances of URI::HTTP.
Global request options (`connection.options`) are copied to the env
hash as env[:request]. This adds the ability to customize these options
per request:
conn.get('/') do |req|
req.options[:timeout] = 10
req.options[:proxy] = {:user => 'dave'}
end
Local options are merged recursively with global ones.
The Request class is not responsible for running itself anymore.
Its `run` methods (both class and instance) are gone.
The actual running of the request is handled by Connection in the
`run_request` method.
