typhoeus/typhoeus — pull request #324 by myronmarston (2013-09-25 13:43:21+00:00)
Title: Failing spec for what I think is a bug

This is the source of vcr/vcr#299.

* When VCR plays back a recorded response, it instantiates a response with `:headers` (a hash) but not `:response_headers` (the raw string containing the headers).
* Typhoeus' faraday adapter uses `:response_headers`, not `:headers`, as seen [here](https://github.com/typhoeus/typhoeus/blob/6a59c62d7e8bda81ec726035b79e035aefd8b05c/lib/typhoeus/adapters/faraday.rb#L97).
* As a result the headers on the faraday response object is an empty hash.

IMO, this is a bug in typhoeus. I've stubbed the headers; the headers should come through when using faraday.

I'm not sure how you want to fix it, though (which is why I'm just submitting a failing spec). Ideas:

* It would be nice if `Typheous::Response`, when given `:headers` but not `:response_headers`, would construct the raw headers string out of the given headers hash so that anything that provides only `:headers` can work with anything that relies upon or uses.
* Alternately, maybe the faraday adapter can be changed to just use `:headers` rather than `:response_headers` (why are you using `:response_headers`, anyway?)

The first seems like a better fix to me as it would fix this for anything that uses `response_headers`. Given that typhoeus provides two representations of the headers, it should take care of making them consistent when only one is provided. It puts a high burden on users to have to provide both and is essentially leaking implementation details out of the interface.