You are viewing a plain text version of this content. The canonical link for it is here.

Posted to modperl@perl.apache.org by "Rafiq Ismail (ADMIN)" <ra...@joshua.dreamthought.com> on 2002/08/08 19:43:24 UTC

$r->internal_redirect

Hi,

I need some advice here.  I've just swiched a apache control layer, from
doing header redirects to internal ones on local addresses, in the content
handler.  This has led to the most bizzar situation.

If I connect to a page which performs an internal_redirect, I obtain the
following results:

	i) When telnetting to 80 and requesting the page, with appropriate
host name:
	403 page
	A point of note is that there is an odd sequence of characters
prior to the the actual page content:



	---------------------------------------------------------

	HTTP/1.1 403 Forbidden
	Date: Thu, 08 Aug 2002 17:30:08 GMT
	Server: Apache/1.3.20 (Linux/SuSE) PHP/4.0.6 mod_perl/1.26
	Transfer-Encoding: chunked
	Content-Type: text/html; charset=iso-8859-1

	10c
	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
	<HTML><HEAD>
	<TITLE>403 Forbidden</TITLE>

	....
	---------------------------------------------------------

	I'm not sure what the 10c is about, but it doesn't appear on
"unredirected" pages.



	ii) When spewing out the page before the $r->print in my handler -
I get the correct, redirected, page dumped in my error logs.

	iii) When viewing the "403" page in a browser, I get a blank page,
with a source of "<html></html>" ; whilst again my error_log still dumps
the correct page.


I'm hoping that this may be something which someother person has seen
before?  Any insights?

Cheers,

fiq

Can I change the browser's address/location?

Posted by Harry Zhu <ha...@GreatLodge.COM>.

Suppose I have a generic content handler to handle requst
/step/1, /step/2, ..., /step/n

<Location /step>
      SetHandler perl-script
      PerlHandler MyHandler

</Location>

#MyHandler.pm
package MyHandler;
sub handler {
  my $r=shift;
  my $step = substr($r->path_info(),1);

  #do something before fetch the content

  #fetch content: usually include a form that will assign action
/step/($step+1)

}

So if everything goes well, the user will follow through from step 1, step
2, until fnish.
Now if in the "#do something ..." part, something is wrong, it will usually
require user go back to the same step, for example, to fill the form again.
The way my old cgi script does is just generate the form with prefilled
value plus some error message indicate what's wrong. It works ok but the
browser location will show /step/($step+1) while it actually is /step/$step.
Now that I am working it on mod-perl I thought I should be able to do
something about it. I briefly browsed the 2 mod-perl books (eagle,
cookbook), and could not found a simple solution yet  (or I missed it?). I
was think using one of the folowing might work:z
1) save the request data in a temp file and redirect or http-refresh to
/step/$step?$session_id or /step/$step/error?$session_id
Remember the content is dynamic and depend on the input form data, so simple
redirect may not work.
Looks like Apache will not post the form data when redirect with Location?

2) print a short form with hidden data and assign action=/step/$step/error
then submit right away (onload=form.submit()?)

Does anybody have a simple solution, e.g. without redirect? Is it possible
to change the URI showing in the browser's address/location bar?

I would appreciated if somebody can pointer me to the right direction.

Harry

Re: $r->internal_redirect

Posted by "Rafiq Ismail (ADMIN)" <ra...@joshua.dreamthought.com>.

On Thu, 8 Aug 2002, Geoffrey Young wrote:
> Rafiq Ismail (ADMIN) wrote:
> > I need some advice here.  I've just swiched a apache control layer, from
> > doing header redirects to internal ones on local addresses, in the content
> > handler.  This has led to the most bizzar situation.
>
> program today).  remember that following $r->internal_redirect you
> should just return OK and not do anything else in your handler.

Cheers, Geoff.  I made a mistake, which the eagle book clearly describes
as a silly assumption.  I'd assumed that the "OK", returned in the
internal_redirect phase was the one being returned to the browser.
Apparently internal_redirect doesn't return anything.  All fixed now.

Thanks for the pointer.

fiq

Re: $r->internal_redirect

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

Rafiq Ismail (ADMIN) wrote:

> Hi,
> 
> I need some advice here.  I've just swiched a apache control layer, from
> doing header redirects to internal ones on local addresses, in the content
> handler.  This has led to the most bizzar situation.

you'll have to share some code if you want us to decypher what you 
mean below (or maybe somebody else does and I'm just not with the 
program today).  remember that following $r->internal_redirect you 
should just return OK and not do anything else in your handler.

[snip]

> 
> 	HTTP/1.1 403 Forbidden
> 	Date: Thu, 08 Aug 2002 17:30:08 GMT
> 	Server: Apache/1.3.20 (Linux/SuSE) PHP/4.0.6 mod_perl/1.26
> 	Transfer-Encoding: chunked
> 	Content-Type: text/html; charset=iso-8859-1
> 
> 	10c
> 	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> 	<HTML><HEAD>
> 	<TITLE>403 Forbidden</TITLE>
> 
> 	....
> 	---------------------------------------------------------
> 
> 	I'm not sure what the 10c is about, but it doesn't appear on
> "unredirected" pages.

that 10c is part of the chunked transfer-encoding - don't worry about 
it.  you can see

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

for more details.

anyway, send some additional information and we'll see what we can do 
for you :)

--Geoff