| Subject: | Authentication/Redirect causes $mech->uri to report incorrect URI |
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.