Re^2: 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

Comment on Re^2: I am having problems with both redirection and detecting redirection Select or Download Code

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]
Re^4: I am having problems with both redirection and detecting redirection by ted.byers (Monk) on Sep 27, 2012 at 18:56 UTC
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]
Re^5: I am having problems with both redirection and detecting redirection by Anonymous Monk on Sep 28, 2012 at 07:09 UTC
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]
Re^6: I am having problems with both redirection and detecting redirection by ted.byers (Monk) on Sep 28, 2012 at 14:23 UTC


Syntactic Confectionery Delight
	PerlMonks