At a high level, there are two ways to craft a response with
FakeWeb.register_uri:
1) :response specifies a string, IO, or filename to be read that has
the entire response, headers and all
2) :string and :file specifies only the response body, and the
headers come from other options passed to .register_uri
When you use the :string or :file options, the content-type of the
response is nil. I'm betting that Mechanize uses that to determine the
class of the pluggable parser to use. When you use the :response
option with a fixture from curl, you probably have a Content-Type
header in your file, which Mechanize parses normally.
This API is a little confusing, IMO... Assuming the
FakeWeb.register_uri API stays the same otherwise, I'd like to
deprecate :string and :file and just use :body instead. It'd behave
the same way as :response, in that you could specify a filename, a
String, or an open-for-reads IO object.
Also, it'd be useful to be able to set the content-type for :string
and :file responses using a :content_type option for
FakeWeb.register_uri... In fact, someone already opened a ticket for
that on GitHub:
http://github.com/chrisk/fakeweb/issues#issue/1
For what it's worth, though, if you're using a full-featured HTTP
client like Mechanize, I'd recommend storing full responses and using
the :response option. Other headers for caching, cookies, encoding,
etc. can be significant, and this will ensure that your tests with
FakeWeb simulate the real tubes as closely as possible.
Chris
On May 25, 7:54 pm, Joshua Clingenpeel <
joshua.clingenp...@gmail.com>
wrote: