Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the WWW-Mechanize CPAN distribution.

Report information
The Basics
Id: 9059
Status: rejected
Priority: 0/
Queue: WWW-Mechanize

Owner: Nobody in particular
Requestors: dan.kubb-cpan [...]

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)


Subject: Authentication/Redirect causes $mech->uri to report incorrect URI
Download (untitled) / with headers
text/plain 1.6k
I found a bug in WWW::Mechanize in how it interacts with an Authenticated application. Here is how I produced the bug: 1. Set $mech->credentials with the proper host, realm, username, and password. 2. Performed a GET request to a Basic Auth protected app to retrieve a web form. 3. Filled in the values of the form. 4. POSTed the form back to the Basic Auth protected app. 5. In response, the application 302 redirected the mech to another URI. 6. Called $mech->uri and the URI reported was the one the POST was sent to (in #4), not the final redirect. Calling $mech->response->request->uri returns the correct value. Tracing through how things work underneath, it appears that the POST in #4 is sent without any credentials on the initial request. The server responds with a 401 and sends the Realm back. LWP silently re-sends a second POST back to the server with the proper credentials. The server responds with a 302 Temporary redirect to a different URI. The Mech/LWP Follows the redirect. So far, so good -- In my testing $mech->uri is set properly right after this step, showing what *should be* the final URI. Then for some reason Mech/LWP *resets* the $mech->uri to match the initial URI from back in step #4. I didn't expect this behaviour. One thing to note: if I look at $mech->response->request->uri returns the proper URI. I always thought that $mech->response->request->uri and $mech->uri should always return an identical value. If so, why not just change $mech->uri to be something like: sub uri { shift->response->request->uri } Of course you'd need checks in case the response object is not yet defined, but you get the idea.
From: rich [...]
Download (untitled) / with headers
text/plain 233b
[guest - Tue Dec 21 03:53:28 2004]: Show quoted text
> sub uri { shift->response->request->uri }
I have found this bug also, and note that it's a regresssion over 1.04 which worked correctly. The suggested workaround (above) works for me. Rich.
Download (untitled) / with headers
text/plain 1.4k
[guest - Tue Dec 21 03:53:28 2004]: Show quoted text
> I found a bug in WWW::Mechanize in how it interacts with an > Authenticated application. Here is how I produced the bug:
I ran into the same problem with a testing framework built around WWW::Mechanize. It happens whenever a redirect occurs. For instance I was testing that a certain page would result in a redirect, and that test started failing after an upgrade to 1.08 from 1.04. What I learned looking at the code: There is an overridden method redirect_ok() which is called by LWP::UserAgent when a redirect occurs. In WWW::Mechanize it updates $self->{redirected_uri} with the correct URL. In 1.04 the code was like this: [...] $self->{req} = $request; $self->{redirected_uri} = $request->uri->as_string; my $res = $self->{res} = $self->_make_request( $request, @_ ); [...] So {redirected_uri} starts out as the original uri, and is possibly updated by redirect_ok() when _make_request() is called. But in 1.08 it changed to this: [...] $self->{req} = $request; $self->{redirected_uri} = $request->uri->as_string; $self->{res} = $res; [...] where _make_request() is called *before* this snippet. So $self->{redirected_uri} always gets overwritten by $request->uri->as_string. I used the attached patch to get it working, but the first comment in this ticket has a better idea, just "recalculate" the value instead of trying to carry it around and keep it up to date.
Download mech.diffs.txt
www/unknown 693b

Message body not shown because it is not plain text.

This a dupe of RT#12882 and should be merged. I'm looking at improving this behavior now. Mark

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to