--00c09f8a54565b1b2c0485ae95c6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi all,
I'm migrating our web server from Apache1.3/modperl1 to Apache2.2/modperl2.
Everything went smoothly (thanks for the great documentation on
perl.apache.org !), until I began to set up FixurHandlers and
CleanUpHandlers to manage the user session.
At that point, I noticed something strange : when the browser requests a
script with a path_info part, my FixupHandler script traces a request on th=
e
path_info part. e.g. an initial request to
http://myserver.domain.com/perl/script.pl/perl/module generates a request t=
o
/perl/script.pl, but also an inner (sub?) request to /perl/module. The
subrequest doesn't seem to call the ResponseHandler, it goes straigth from
Fixup to CleanUp.
So I see this:
[MapToStorage] /perl/script.pl/perl/module
[Fixup] /perl/script.pl
[MapToStorage] /perl/module
[Fixup] /perl/module
[CleanUp] /perl/module
[Response] /perl/script.pl
[CleanUp] /perl/script.pl
It's kinda strange, since /perl/module is just a path_info, but I can live
with that. The problem is that my Fixup handler tries to actually fix thing=
s
up for the upcoming request, like tie-ing a variable for my session. When
there's no actual request, I'm tie-ing the variable for nothing, and it's
detrimental.
So I have two questions :
Can I prevent the subrequest ? Maybe a return value to the main Fixup
handler ?
Can I inspect the subrequest to know that it is a subrequest ? Maybe a $r
method ?
Thanks for your time,
C=E9dric Bertolini
--00c09f8a54565b1b2c0485ae95c6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<font color=3D"#663300"><font face=3D"georgia,serif">Hi all,<br><br>I'm=
migrating our web server from Apache1.3/modperl1 to Apache2.2/modperl2. Ev=
erything went smoothly (thanks for the great documentation on <a href=3D"ht=
tp://perl.apache.org">perl.apache.org</a> !), until I began to set up Fixur=
Handlers and CleanUpHandlers to manage the user session.<br>
<br>At that point, I noticed something strange : when the browser requests =
a script with a path_info part, my FixupHandler script traces a request on =
the path_info part. e.g. an initial request to <a href=3D"http://myserver.d=
omain.com/perl/script.pl/perl/module">http://myserver.domain .com/perl/scrip=
t.pl/perl/module</a> generates a request to /perl/<a href=3D"http://script.=
pl">script.pl</a>, but also an inner (sub?) request to /perl/module.=A0 The=
subrequest doesn't seem to call the ResponseHandler, it goes straigth =
from Fixup to CleanUp.<br>
<br>So I see this:<br><br>[MapToStorage] /perl/<a href=3D"http://script.pl/=
perl/module">script.pl/perl/module</a><br>[Fixup]=A0 /perl/<a href=3D"http:=
//script.pl">script.pl</a><br>[MapToStorage] /perl/module<br>[Fixup] /perl/=
module<br>
[CleanUp] /perl/module<br>[Response] /perl/<a href=3D"http://script.pl">scr=
ipt.pl</a><br>[CleanUp] /perl/<a href=3D"http://script.pl">script.pl</a><br=
><br>It's kinda strange, since /perl/module is just a path_info, but I =
can live with that. The problem is that my Fixup handler tries to actually =
fix things up for the upcoming request, like tie-ing a variable for my sess=
ion. When there's no actual request, I'm tie-ing the variable for n=
othing, and it's detrimental.<br>
<br>So I have two questions :<br><br>Can I prevent the subrequest ? Maybe a=
return value to the main Fixup handler ?<br>Can I inspect the subrequest t=
o know that it is a subrequest ? Maybe a $r method ?<br><br>Thanks for your=
time,<br>
C=E9dric Bertolini<br><br></font></font>
--00c09f8a54565b1b2c0485ae95c6--
