http://www.perlmonks.org?node_id=995896


in reply to Re: I am having problems with both redirection and detecting redirection
in thread I am having problems with both redirection and detecting redirection

Thanks. That was it.

From the output I now see, I can use $reponse->code to detect the redirection.

Now, how do I proceed to the next step, which is to send that redirection, unaltered, back to the client that made the original request to my cgi script. That is, imagine my client code above being in a CGI script that submits a request to a secure site, and if I get a redirect, I have to pass it back to the client that submitted the original request to my CGI script. How do I do this? Surely it isn't as simple as:

print $cgi->redirect($response->request);

But that is what would be implied by the following from the documentation:

$r->request
$r->request( $request )

    This is used to get/set the request attribute. The request attribu
+te is a reference to the the request that caused this response. It do
+es not have to be the same request passed to the $ua->request() metho
+d, because there might have been redirects and authorization retries 
+in between.

[download]

If it is that simple, would any headers I may have printed before printing the redirect adversely affect how the redirect works, or do I have to ensure that nothing, not even headers, get printed before I know whether or not a redirection has occured?

Thankyou very much.

Ted

Replies are listed 'Best First'.
Re^3: I am having problems with both redirection and detecting redirection
by Anonymous Monk on Sep 27, 2012 at 02:38 UTC

    escape, encode, serialize ... 

    $cgi->redirect( '?what='. CGI->escape( $res->headers->as_string ) );

    [download]

    unescape, decode, deserialize ... 

    my $what = $cgi->param('what') || $cgi->query_param('what');
my $headers HTTP::Message->parse( $what )->headers;

    [download]
[reply]
[d/l]
[select]

      Thanks.

      That looks liek what I would do if I am generating the redirection myself, and handling it directly in my script rather than passing it on to the client. However, why don't I just use the following:

      print $response->as_string;

      For my test cgi script, and using my client scriptlet, that gives me the following:

      HTTP/1.1 302 Found
Connection: close
Date: Thu, 27 Sep 2012 15:43:16 GMT
Location: http://localhost:9080/cgi-bin/cgi.redirect.pl
Server: Apache/2.2.16 (Win32) mod_ssl/2.2.16 OpenSSL/0.9.8o PHP/5.3.3
Content-Type: text/plain
Client-Date: Thu, 27 Sep 2012 15:43:16 GMT
Client-Peer: 127.0.0.1:9080
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Client-Warning: Redirect loop detected (max_redirect = 0)

<!DOCTYPE html
    PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-U
+S">
<head>
<title>Redirection Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1
+" />
</head>
<body>
<p><a href="http://www.google.ca">Go To Google</a></p>
</body>
</html>

      [download]

      If I get a redirection, the only thing I ought to do in this use case is pass it on to whatever client sent a request to my CGI script, and it looks like "print $response->as_string;" will do that: request parameters and all. It is true I need to store some data in this eventuality, but that is just an extra function call inside the conditional block that checks to see whether or not the response code is between 300 and 399 inclusive., That, and not allowing my code to follow redirections, ought to suffice. Is there any reason to expect that to break?

      Thanks again.

      Ted

[reply]
[d/l]
[select]

        However, why don't I just use the following:

        I don't know, doesn't make sense to me -- you're not a proxy, so why act like a proxy -- either you're making requests on behalf of a user or the user is making the requests -- redirecting a user to some other site based on a request you generated to that other site, smells like CSRF

        Is there any reason to expect that to break?

        Sure, if the other site changes, say to ban your client (for TOS) or prevent CSRF :)

        But I'm not really sure what you're doing :)

[reply]

In Section Seekers of Perl Wisdom