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

Bug #344680 reported by Malthe Borch on 2009-03-18
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zope 3
Undecided
Unassigned
zope.testbrowser
Low
Unassigned

Bug Description

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.

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) wrote :

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

Tres Seaver (tseaver) on 2010-04-15
Changed in zope3:
status: New → Won't Fix
Tres Seaver (tseaver) on 2010-05-10
Changed in zope.testbrowser:
importance: Undecided → Low
status: New → Triaged

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

"Using mechanize request objects wasn't intentionally supported"

But supporting urllib2.Request objects is reasonable though?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers