Odd behavior with FakeWeb and Mechanize

[Joshua Clingenpeel]

Mechanize seems to keep coming up. I'll try to keep this brief.

mechanize v0.9.2
fakeweb v1.2.2

I'm registering a URI with fakeweb and telling it to use a local file
with the :file param. The file is just a copy of the page source as
viewed in Firefox v3.0.8. When I run Mechanize.get on the local file,
I get an object of type WWW::Mechanize::Page. When I run Mechanize.get
on the URI, something in FakeWeb is causing the resulting object to be
of type WWW::Mechanize::File, which is a sort of placeholder class for
content types that Mechanize doesn't know what to do with.

I tried to resolve this with a 'curl -is' to generate my local cache.
I thought that the issue was missing header data in the file. Again
this came back as WWW::Mechanize::File. Finally I changed my
register_uri call to this:

FakeWeb.register_uri("http://www.nanowrimo.org/eng/user/
240659", :response => File.read("local_file.htm"))

And this worked, FakeWeb was able to give me a WWW::Mechanize::Page
object.

So why would Mechanize.get("copy_of_firefox_source.htm") work until
FakeWeb was involved?

Let me know if you need any more information. If this is a bug that
needs fixin', I'll be happy to work on it.

[Chris Kampmeier]

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: