Re: Internal redirect inside an input filter

[Torsten Foertsch]

On Thu 09 Oct 2008, Dan DeSmet wrote:
 I'm attempting to write an input filter that performs an internal
 redirect based on the contents of the cookies sent in the request
 headers.

Why an input filter? What you want is better done in a PerlTransHandler 
or a PerlFixupHandler.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]

Re: Internal redirect inside an input filter

[Dan DeSmet]

I took your advice and tried switching it over to a TransHandler.  Now, the
beginning of the handler where I manipulate the cookies looks like this:

sub handler {
my $r = shift;
my $cookieString = $r-headers_in-get('Cookie');
...
}

I then do a check to see if the cookies exist; that tells me whether it's a
client's first request, or a subsequent one.  I then need to read a bunch of
information out of the cookies and then rewrite one of them.  Unfortunately,
the above code always yields me an empty string.  I can check my browser
cookies and see that they've been set correctly.  Can the TransHandler
manipulate the request headers apart from the URI?  Or am I just missing
something?

Thanks,
Dan

On Thu, Oct 9, 2008 at 8:50 AM, Torsten Foertsch
[EMAIL PROTECTED]wrote:

 On Thu 09 Oct 2008, Dan DeSmet wrote:
  I'm attempting to write an input filter that performs an internal
  redirect based on the contents of the cookies sent in the request
  headers.

 Why an input filter? What you want is better done in a PerlTransHandler
 or a PerlFixupHandler.

 Torsten

 --
 Need professional mod_perl support?
 Just hire me: [EMAIL PROTECTED]

Re: Internal redirect inside an input filter

[Dan DeSmet]

Thanks for your help.  Your confirmation led me to track down the real
problem, which is that I marked the cookies secure, and forgot to do https
rather than http in my browser URL.  If not for your help, there's no
telling how long I would've spent trying to fix a problem in my code that
didn't exist.

Thanks.

On Thu, Oct 9, 2008 at 10:07 AM, Torsten Foertsch
[EMAIL PROTECTED]wrote:

 On Thu 09 Oct 2008, Dan DeSmet wrote:
  I took your advice and tried switching it over to a TransHandler.
   Now, the beginning of the handler where I manipulate the cookies
  looks like this:
 
  sub handler {
  my $r = shift;
  my $cookieString = $r-headers_in-get('Cookie');
  ...
  }
 
  I then do a check to see if the cookies exist; that tells me whether
  it's a client's first request, or a subsequent one.  I then need to
  read a bunch of information out of the cookies and then rewrite one
  of them.  Unfortunately, the above code always yields me an empty
  string.  I can check my browser cookies and see that they've been set
  correctly.  Can the TransHandler manipulate the request headers apart
  from the URI?  Or am I just missing something?

 I have just checked it using the following TransHandler (directly
 implemented in the httpd.conf):

 PerlTransHandler sub { \
  my ($r)[EMAIL PROTECTED]; \
  warn qq{Got Cookie: }.$r-headers_in-{Cookie}; \
  return Apache2::Const::DECLINED; \
 }

 Now, I call:

 curl -v http://localhost
 * About to connect() to localhost port 80 (#0)
 *   Trying 127.0.0.1... connected
 * Connected to localhost (127.0.0.1) port 80 (#0)
  GET / HTTP/1.1
  User-Agent: curl/7.18.1 (x86_64-suse-linux-gnu) libcurl/7.18.1
 OpenSSL/0.9.8g zlib/1.2.3 libidn/1.8
  Host: localhost
  Accept: */*
 ...

 No cookie is transmitted and in the error_log appears the line:

 Got Cookie:  at (eval 91) line 1.

 But if I call this:

 curl -v -b 'klaus=otto' http://localhost
 * About to connect() to localhost port 80 (#0)
 *   Trying 127.0.0.1... connected
 * Connected to localhost (127.0.0.1) port 80 (#0)
  GET / HTTP/1.1
  User-Agent: curl/7.18.1 (x86_64-suse-linux-gnu) libcurl/7.18.1
 OpenSSL/0.9.8g zlib/1.2.3 libidn/1.8
  Host: localhost
  Accept: */*
  Cookie: klaus=otto
 ...

 You see the cookie-header? In the error_log I see:

 Got Cookie: klaus=otto at (eval 91) line 1.

 So, yes, you can manipulate request headers in the translation phase. In
 fact, they are already accessible even in a PerlPostReadRequestHandler
 which comes before the PerlTransHandler and is the very first occasion
 when a Perl module can interfere. The main difference between
 postreadrequest and translation is that the former is skipped for
 subrequests and internal redirects. You can try my little handler as
 PerlPostReadRequestHandler and will see the same result.

 Torsten

 --
 Need professional mod_perl support?
 Just hire me: [EMAIL PROTECTED]