On Sat Sep 12 13:06:03 2009, DROLSKY wrote:
Show quoted text> On Thu Aug 20 10:59:22 2009, JSHIRLEY wrote:
> > Hi Dave,
> >
> > I was writing some live tests, intending to go down the browser path
> > and noticed that my
> > checks to $c->req->looks_like_browser fail during POST (but not GET).
> >
> > The reason is the header specifies content-type: application/x-www-
> > form-urlencoded
> > , which fails the check of an HTMLTypes in the map.
> >
> > It seems, at first glance, the right "fix" is to add application/x-
> > www-form-urlencoded as a
> > valid entry in %HTMLTypes.
>
> So I looked at this a little more, and now I'm confused.
>
> Firefox, at least, provides the same Accept header on a POST as its does
> on a GET. That should cause looks_like_browser to return true.
>
> Second, adding the form content type to the list of HTML types won't
> help. I'd have to check the request content type itself. That seems like
> a bad idea, since I can easily imagine a non-browser client using the
> same content types for POSTs as a browser.
Well, the problem is inconsistent behavior with WWW::Mechanize.
A WWW::Mechanize GET request passes $c->req->looks_like_browser, but a
POST fails.
I'm fine submitting a patch to WWW::Mechanize to get consistent
behavior, but should we define that based on Firefox behavior (of
including Accept on POST?)
(In personal context, I rely on WWW::Mechanize for my RESTful tests
mimicking a browser. I use LWP clients for the !browser tests)
