Missing support for request-object in zope.testbrowser after r84900

[Malthe Borch]

Code snippet:

>>> def open(self, url, data=None):
>>> """See zope.testbrowser.interfaces.IBrowser"""
>>> url = str(url)

This string coercion is unfortunate, because ``mechanize`` accepts a
(mechanize-) request-object in place of a URL string here. Using a
custom request object allows us to do such things as setting the
REQUEST_TYPE header string, which is not possible throught the
standard API.

Changeset comment:

- Remove vendor import of mechanize.

- Fix bug that caused HTTP exception tracebacks to differ between
 version 3.4.0 and 3.4.1.

- Workaround for bug in Python Cookie.SimpleCookie when handling
 unicode strings.

- Fix bug introduced in 3.4.1 that created incompatible tracebacks in
 doctests. This necessitated adding a patched mechanize to the
 source tree; patches have been sent to the mechanize project.

Not sure which of the above this coercion is trying to solve, but
perhaps it could be solved in a way that didn't break the mechanize
functionality.

[Benji York (benji)]

On Wed, Mar 18, 2009 at 3:33 AM, Malthe <email address hidden> wrote:
> Public bug reported:
>
> Code snippet:
>
>>>>    def open(self, url, data=None):
>>>>       """See zope.testbrowser.interfaces.IBrowser"""
>>>>        url = str(url)
>
> This string coercion is unfortunate, because ``mechanize`` accepts a
> (mechanize-) request-object in place of a URL string here. Using a
> custom request object allows us to do such things as setting the
> REQUEST_TYPE header string, which is not possible throught the
> standard API.

Using mechanize request objects wasn't intentionally supported (hence
the lack of tests for it). Mechanize is just an implementation detail
of testbrowser, mechanize shouldn't be exposed to users of testbrowser.

What do you want mechanize request object support for?

[Malthe Borch (mborch)]

2009/3/18 Benji York <email address hidden>:
> Using mechanize request objects wasn't intentionally supported (hence
> the lack of tests for it).  Mechanize is just an implementation detail
> of testbrowser, mechanize shouldn't be exposed to users of testbrowser.

Makes sense.

> What do you want mechanize request object support for?

It's nice to be able to provide a request object which sets the method
to e.g. "PUT". I'm sure there are other use-cases.

\malthe

[Anthony Gerrard (anthonygerrard+launchpad-net)]

It is actually a useful feature to support testing HTTP methods other than GET. e.g. I have a genuine requirement to test how my application handles HEAD requests to images. Previously I could test this using testbrowser and I even blogged about it here

http://www.scarba05.co.uk/blog/2012/01/how-to-test-sending-a-http-head-request-to-plone-zope/

The code is wrong anyway. e.g. if someone passes in None do we really want to send a request to the relative url 'None'?

From the commit comment the change was made to support unicode. The attached patch should satisfy both requirements

[Anthony Gerrard (anthonygerrard+launchpad-net)]

"Using mechanize request objects wasn't intentionally supported"

But supporting urllib2.Request objects is reasonable though?

[Colin Watson (cjwatson)]

The zope.testbrowser project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope.testbrowser.