Posting Form with LWP Produces 'no-cache, must revalidate' Error

[sierrathedog04]

The following script is an attempt to automate the remote administration of my website using LWP. It attempts to submit the fields 'email' and 'passwd.'

# Jonathan S. Mark [e-mail]
# Program to log on to Alxnet

use strict;
use LWP;
use HTTP::Request::Common;

use constant ALX_ENTER => 'http://www.alxnet.com/controlcenter/';
use constant ALX_REFERER => 'http://www.alxnet.com';

my $ua = LWP::UserAgent->new;
my $newagent = 'enter_alxnet/1.0 (' . $ua->agent . ')'; #identifies ap
+p to net. Not important.
$ua->agent($newagent);

my $request = POST (ALX_ENTER, Content => [email => 'jonathansamuel@ya
+hoo.com', passwd => 'subforactualvalue', t => 'alxnet_signup'], Refer
+er => ALX_REFERER);
my $response = $ua->request($request)->as_string;
print $response;

Unfortunately, running this LWP script returns a message from the server similar to the following:

HTTP/1.1 302 Found Cache-Control: no-cache, must-revalidate Connection: close Date: Sun, 12 Aug 2001 10:31:11 GMT Pragma: no-cache Location: /controlcenter/?u=100000&p=0x1000000000000 Server: Apache/1.3.17 (Unix) PHP/4.0.4pl1 mod_perl/1.25 Content-Type: text/html Expires: Mon, 26 Jul 1990 05:00:00 GMT Last-Modified: Sun, 12 Aug 2001 10:31:13GMT Client-Date: Sun, 12 Aug 2001 11:38:28 GMT Client-Peer: 209.92.32.185:80

Can anyone clue me in what is going on here. What does 'no-cache, must revalidate' mean? What do I have to do using LWP to avoid this problem?

[andye]

Let's see now... certain amount of guesswork in places, but for what it's worth...

First, it's not an error message as such, it's a normal http response. It says at the start that it's HTTP/1.1, so let's have a look at the RFC... Looks like RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 is the one you want.

Next bit of the response: 302 Found. This is covered in section 10.3.2 of the RFC, and a bit higher up it explains that all the 3xx codes are to do with redirection. 302 found means that The requested resource resides temporarily under a different URI.

Now The temporary URI SHOULD be given by the Location field in the response. So it looks like this is a redirection from your original request, /controlcenter/, to /controlcenter/?u=100000&p=0x1000000000000 - interesting(ish).

(The bit you were worried about, Cache-Control: no-cache, must-revalidate, just indicates that this response shouldn't be cached).

Now LWP can, afair, follow redirections for you if you tell it to, but it can't in this case even if you *do* tell it to, because If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. - and our request was, of course, a POST, so the LWP module "MUST NOT" (this is RFC-language for "really really shouldn't, we mean it") follow the redirection automatically.

So what could you do?

• try GET
• now you're expecting the redirection, you could follow it (maybe LWP can help you with this)
• use the other URL, like the other poster said ;)

I've been into this point-by-point not out of any intention to be patronising, but to assist those monks who might not have come across the RFCs before - they can be v.useful.

hth, andy.

[blakem]

Welcome back STD4! Glad you've returned.

I took a brief look at alxnet.com and noticed that one form sends you to /controlcenter, and another sends you to /controlcenter/login/. Have you tried sending your POST to the second one?

-Blake

[sierrathedog04]

Thanks to Andy and Blakem for their help. Following the link did not work, it seemed to return the same error as before. I was not able to get PUT or GET to work, something about a bad header.

The url I am posting to, /controlcenter/ is the action for the form I am submitting.

I did, however, notice something about the server's response. It said that the server is using HTTP 1.1. The documentation on CPAN for the LWP module says that "The libwww-perl HTTP implementation currently support the HTTP/1.0 protocol." So maybe that is the problem. I will look into it.