Internal redirect inside an input filter - modperl

This is a discussion on Internal redirect inside an input filter - modperl ; 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. The problem I'm encountering is that the browser is receiving both the content for the original ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Internal redirect inside an input filter

  1. Internal redirect inside an input filter

    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. The
    problem I'm encountering is that the browser is receiving both the content
    for the original request, as well as the content generated by the internal
    redirect. Ideally, the browser would receive only the content generated
    from the internal redirect. Here is a sample filter I wrote while trying to
    solve this problem:

    package Test::Redirect;

    # a bunch of use statements

    sub handler : FilterRequestHandler {

    my $f = shift;
    # this is just any old uri
    $f->r->internal_redirect('/reverse');
    return Apache2::Const::OK;
    }

    I've tried setting the filter's context to allow it to run only once, but if
    I do that, it never completes the request. Any ideas?

    Thanks,
    Dan


  2. Re: Internal redirect inside an input filter

    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: torsten.foertsch@gmx.net


  3. Re: Internal redirect inside an input filter

    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
    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: torsten.foertsch@gmx.net
    >



  4. Re: Internal redirect inside an input filter

    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)=@_; \
    warn qq{Got Cookie: }.$r->headers_in->{Cookie}; \
    return Apache2::Const:ECLINED; \
    }"

    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: torsten.foertsch@gmx.net


  5. Re: Internal redirect inside an input filter

    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
    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)=@_; \
    > warn qq{Got Cookie: }.$r->headers_in->{Cookie}; \
    > return Apache2::Const:ECLINED; \
    > }"
    >
    > 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: torsten.foertsch@gmx.net
    >



+ Reply to Thread