[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: questions on Apache2::Connection
From:       Torsten Foertsch <torsten.foertsch () gmx ! net>
Date:       2008-10-11 17:08:36
Message-ID: 200810111908.36506.torsten.foertsch () gmx ! net
[Download RAW message or body]

On Sat 11 Oct 2008, André Warnier wrote:
> 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.

Yes, connection notes and connection pnotes are persistent across 
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 
connection to the backend but server different clients and thus spoil 
your caching.

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

Torsten

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

[prev in list] [next in list] [prev in thread] [next in thread]