questions on Apache2::Connection

Hi gurus.

Do I understand this correctly that if in a Perl Handler i get
my $c = $r->connection();
then $c is the object that represents the persistent TCP/IP connection
between the browser and the server, in case there is "keep-alive" going on ?

Now lets say that I create an authentication method based on the Request
(as they tend to be usually).
On the first request, the authentication happens, and I set a
$c->notes('credentials') value. I also set a browser cookie.

On subsequent requests, I could check this $c->notes('credentials')
first, in case a previous request over the same connection already
resulted in authentication, could I not ?

In the worst case, the connection is new and I would not have these
notes (meaning I then need to get the cookie, and in its absence redo an
authentication); but in the vast majority of cases (depending on
keep-alive), I could save myself some overhead by considering the
connection as authenticated instead of the request, no ?

Or are there some pitfalls here of which I am ignorant ?
Or is the potential gain not worth the cost of getting the $r->connection ?

Thanks for opinions.

Re: questions on Apache2::Connection

André Warnier wrote:
> Hi gurus.
>
> Do I understand this correctly that if in a Perl Handler i get
> my $c = $r->connection();
> then $c is the object that represents the persistent TCP/IP connection
> between the browser and the server, in case there is "keep-alive" going
> on ?
>
> Now lets say that I create an authentication method based on the Request
> (as they tend to be usually).
> On the first request, the authentication happens, and I set a
> $c->notes('credentials') value. I also set a browser cookie.
>
> On subsequent requests, I could check this $c->notes('credentials')
> first, in case a previous request over the same connection already
> resulted in authentication, could I not ?

I just read the docs, and though it doesn't explicitly say that that
that would, or wouldn't work, but the existance of $c->keepalives()
makes me think that it would work. It'd be pretty easy to confirm
though, so i'd suggest you do that.

> In the worst case, the connection is new and I would not have these
> notes (meaning I then need to get the cookie, and in its absence redo an
> authentication); but in the vast majority of cases (depending on
> keep-alive), I could save myself some overhead by considering the
> connection as authenticated instead of the request, no ?
>
> Or are there some pitfalls here of which I am ignorant ?
> Or is the potential gain not worth the cost of getting the $r->connection ?

If you've got a heavily trafficked site, and confirming that your auth
cookies are valid is expensive, then doing something like this could
make sense. How much of an effect it's going to have is something that
would be very dependent on the clients your site has more than anything
though. You'd might want to do some investigation into how much of your
traffic actually comes from from requests through a connection that was
kept-alive by keep-alive.

It is an interesting idea though.

Adam

Re: questions on Apache2::Connection

On Sat 11 Oct 2008, Andr=E9 Warnier wrote:
> Do I understand this correctly that if in a Perl Handler i get
> my $c =3D $r->connection();
> then $c is the object that represents the persistent TCP/IP
> connection between the browser and the server, in case there is
> "keep-alive" going on ?
>
> Now lets say that I create an authentication method based on the
> Request (as they tend to be usually).
> On the first request, the authentication happens, and I set a
> $c->notes('credentials') value. I also set a browser cookie.

Yes, connection notes and connection pnotes are persistent across=20
keep-alive requests.

> On subsequent requests, I could check this $c->notes('credentials')
> first, in case a previous request over the same connection already
> resulted in authentication, could I not ?
>
> In the worst case, the connection is new and I would not have these
> notes (meaning I then need to get the cookie, and in its absence redo
> an authentication); but in the vast majority of cases (depending on
> keep-alive), I could save myself some overhead by considering the
> connection as authenticated instead of the request, no ?
>
> Or are there some pitfalls here of which I am ignorant ?
> Or is the potential gain not worth the cost of getting the
> $r->connection ?

I see 2 points to consider:

1) A reverse proxy in front of the web server can maintain a persistent=20
connection to the backend but server different clients and thus spoil=20
your caching.

2) The combination of prefork-MPM, mod_perl and keep-alive is perilous=20
on the Internet because one apache process is locked over the whole=20
keep-alive time. A malicious client sends one request and let the kept=20
alive connection time out by the server. A single client can eat up all=20
your servers in a very short time. Of course a similar attack is=20
possible based on the server's TimeOut setting but they are a bit=20
trickier. You deploy that combination directly on the Internet but you=20
have to have a close look at the TimeOut and KeepAliveTimeout settings.=20
Make them as short as you can.

Torsten

=2D-
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net