pengwynn/faraday_middleware — pull request #24 by nbibler (2012-03-03 21:24:31+00:00)
Title: Add more 'proper' redirection handling

This pull request is in reference to issue #23.

This update adds better redirection capability to the middleware stack. It adds HTTP 307 handling, by replaying the original request (including method) to the returned Location. It also adds support for HEAD and OPTIONS requests, by not redirecting those, at all.

This implementation also treats HTTP 302 and HTTP 303 identically. This was a trade-off requested by @mislav to better mimic browser implementations. It is trivial to convert this implementation to a "proper" implementation, where HTTP 302 would replay the original request by simply changing one line of code (`:get` becomes `:any` in a constant).

There is one `FIXME` that I added in the new specs, because the test adapter's connection appears to be overriding the `options` http connection method. I would have liked to test that OPTIONS requests were not being redirected, but due to the override (which I didn't quickly locate, so I gave up on it), I was unable to do so.

I've also added **significantly more** specs around the middleware, as shown below:

```
$ rspec --format doc spec/follow_redirects_spec.rb

FaradayMiddleware::FollowRedirects
returns non-redirect response results
follows a single redirection
follows many redirections
raises a FaradayMiddleware::RedirectLimitReached after 3 redirections (by default)
raises a FaradayMiddleware::RedirectLimitReached after the initialized limit
for an HTTP 301 response
it should behave like a successful redirection
follows the redirection for a GET request
returning the response headers for a HEAD request
it should behave like a forced GET redirection
a PUT request is converted to a GET
a POST request is converted to a GET
a DELETE request is converted to a GET
a PATCH request is converted to a GET
for an HTTP 302 response
it should behave like a successful redirection
follows the redirection for a GET request
returning the response headers for a HEAD request
it should behave like a forced GET redirection
a PUT request is converted to a GET
a POST request is converted to a GET
a DELETE request is converted to a GET
a PATCH request is converted to a GET
for an HTTP 303 response
it should behave like a successful redirection
follows the redirection for a GET request
returning the response headers for a HEAD request
it should behave like a forced GET redirection
a PUT request is converted to a GET
a POST request is converted to a GET
a DELETE request is converted to a GET
a PATCH request is converted to a GET
for an HTTP 307 response
a PUT request is replayed as a PUT request to the new location
a POST request is replayed as a POST request to the new location
a DELETE request is replayed as a DELETE request to the new location
a PATCH request is replayed as a PATCH request to the new location
it should behave like a successful redirection
follows the redirection for a GET request
returning the response headers for a HEAD request

Finished in 0.01076 seconds
29 examples, 0 failures
```