This queue is for tickets about the Catalyst-Request-REST-ForBrowsers CPAN distribution.

Report information
The Basics
Id:
48882
Status:
resolved
Priority:
Low/Low

People
Owner:
DROLSKY [...] cpan.org
Requestors:
jshirley+cpan [...] gmail.com
Cc:
AdminCc:

BugTracker
Severity:
Normal
Broken in:
0.02
Fixed in:
(no value)



Subject: Inconsistent behavior with WWW::Mechanize (not sure this is a bug here?)
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. Thanks, -J
On Thu Aug 20 10:59:22 2009, JSHIRLEY wrote:
Show quoted text
> 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.
I've honestly never imagined anyone would care to check looks_like_browser except for GET requests. But yes, I should probably add this type to the list of HTMLTypes (and rename that to BrowserTypes).
On Thu Aug 20 10:59:22 2009, JSHIRLEY wrote:
Show quoted text
> 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.
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)
Subject: Re: [rt.cpan.org #48882] Inconsistent behavior with WWW::Mechanize (not sure this is a bug here?)
Date: Sat, 12 Sep 2009 12:28:20 -0500 (CDT)
To: "J. Shirley via RT" <bug-Catalyst-Request-REST-ForBrowsers@rt.cpan.org>
From: Dave Rolsky <autarch@urth.org>
On Sat, 12 Sep 2009, J. Shirley via RT wrote:
Show quoted text
> 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?)
Yes. Of course a client should include Accept on POST. After all, POST can return content too! -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
I'm just going to mark this as resolved. I did some light digging and it seems that beating the underlying tools into shape is the right solution, though a hefty one. Thanks Dave! -J


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.