You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Greg Cope <gr...@rubberplant.freeserve.co.uk> on 2000/10/29 18:24:41 UTC
[ ANNOUNCE ] Apache::SessionManager-0.06
Dear All
I've finally got a tar ball onto sourceforge (but that's another [OT]
story ;-)
Announcing Apache::SessionManager.
For those that do not know this is a (near) Transparent Session Manager
module - it will get (and optionally set) a Session ID from a client
request. It does no more that this with the ID - authenticating it /
checking validity is up to you. It is supposed to compliment
Apache::Session, which can be used as the backbend session store.
It has some perldoc in the Apache::SessionManager.pm file.
There is an example startup.pl in the example dir. of the tar ball.
It is quite configurable in that you can change its behaviour to taste -
see the perldoc / source.
It works in my development environment.
It is BETA and the API may change. Use it at your own risk! The usual
warranty applies - in that if it breaks please send any bits to
/dev/null, and any patches / bug fixes to me!
Please send me any feedback directly.
A BIG thank you to all that have help / sent me feedback / ideas, and
also to Doug for mod_perl and the Apache and perl authors.
Oh, Find it here:
http://sourceforge.net/projects/sessionmanager/
Regards
Greg Cope
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Greg Cope <gr...@rubberplant.freeserve.co.uk>.
"G.W. Haywood" wrote:
>
> Hi there,
>
> On Mon, 30 Oct 2000, Greg Cope wrote:
>
> > In theory there is no reason why this should not be translateable to C,
> > it is quite small (in perl).
> > However:
> > a) I cannot do C (and translating this is beyond me as a learning
> > exercise at the mo).
> > b) Also waiting is a good idea till all the bugs are sorted. (I am sure
> > there are more).
>
> I think it's right to turn things like this into C. I'll help you
> with it if you like, but I think you're right about waiting until the
> design is stable before doing it.
>
> If you can write Perl you can write C, there are onlya couple of dozen
> keywords. It's just that you're not so mollycoddled in C, you're much
> closer to the machine, and you have to plan further ahead (instead of
> waiting for the bang:). I prefer it.
Thank you Ged.
I have been meaning to learn C (along with lots of other things).
Any good books to recommend - I've got practicle C from O'Reilly - I
need something that is not too dry and manpage ish, but also not an
idiots guide as I can do perl (well I think I can).
I've been toying with the idea of C as this would push it out of the
mod_perl areana. The logic of it is quite simple. But for a beginer it
look all to complex. Plus there is the minor issue of time !
Thanks again for the offer of help, I may take you up on that.
Greg
> 73,
> Ged.
Re: [OT][ ANNOUNCE ] Apache::SessionManager-0.07
Posted by "G.W. Haywood" <ge...@www.jubileegroup.co.uk>.
Hi Gerald,
On Mon, 30 Oct 2000, Gerald Richter wrote:
> Also there are a lot of nice libraries around, programming in C will
> always take much more time (I would say 2 to 10 times), then writing
> the same in Perl.
Good to have confirmation of my suspicions!
73,
Ged.
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Gerald Richter <ri...@ecos.de>.
> >
> > I think you're forgetting about little things like regexes and such.
Yes,
> > Perl and C share a lot of syntax, but there are many things you can do
> > easily in Perl that are brutal in C.
>
> I agree but apache has regex.h ... a regex libary - hence these should
> be possible - or am I missing the point ?
>
Also there are a lot of nice libraries around, programming in C will always
take much more time (I would say 2 to 10 times), then writing the same in
Perl.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Dave Rolsky <au...@urth.org>.
On Mon, 30 Oct 2000, Greg Cope wrote:
> I agree but apache has regex.h ... a regex libary - hence these should
> be possible - or am I missing the point ?
My point was simply that while Perl makes easy things easy, C makes all
things hard ;)
Frankly, I prefer it as a Perl module since I can see myself hooking it
together with Apache::Session and using them together.
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
Re: [OT][ ANNOUNCE ] Apache::SessionManager-0.07
Posted by "G.W. Haywood" <ge...@www.jubileegroup.co.uk>.
Hi Greg,
On Mon, 30 Oct 2000, Greg Cope wrote:
> I agree but apache has regex.h ... a regex libary - hence these should
> be possible - or am I missing the point ?
Actually regex.h is just a header file which contains the definitions
(functions, data structures etc) for the library. There are often
many libraries to do the same or similar things, just like there are
many modules on CPAN which do similar things. There are open source
libraries and commercial ones.
But Dave's right, a lot of things that are a couple of lines in Perl
are a real pain in C. I generally make a choice fairly early on about
which to use and then stick with it. The choice is based on past
experience but it's usually pretty obvious how it will go.
Generally it will take you five times as long to code something in C
as it will in Perl. But it will often run five times faster and more
reliably. Ask yourself why Apache (or even Linux for that matter)
wasn't written in Perl in the first place.
Horses for courses.
73,
Ged.
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Greg Cope <gr...@rubberplant.freeserve.co.uk>.
Dave Rolsky wrote:
>
> On Mon, 30 Oct 2000, G.W. Haywood wrote:
>
> > If you can write Perl you can write C, there are onlya couple of dozen
> > keywords. It's just that you're not so mollycoddled in C, you're much
> > closer to the machine, and you have to plan further ahead (instead of
> > waiting for the bang:). I prefer it.
>
> I think you're forgetting about little things like regexes and such. Yes,
> Perl and C share a lot of syntax, but there are many things you can do
> easily in Perl that are brutal in C.
I agree but apache has regex.h ... a regex libary - hence these should
be possible - or am I missing the point ?
Greg
>
> -dave
>
> /*==================
> www.urth.org
> We await the New Sun
> ==================*/
Re: [OT] [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by "G.W. Haywood" <ge...@www.jubileegroup.co.uk>.
Hi Dave,
On Mon, 30 Oct 2000, Dave Rolsky wrote:
> On Mon, 30 Oct 2000, G.W. Haywood wrote:
> > If you can write Perl you can write C, there are onlya couple of dozen
> > keywords.
>
> I think you're forgetting about little things like regexes and such.
Maybe glossing over, not forgetting - that's what libraries are for!
But I agree you need to choose your tools thoughtfully.
73,
Ged.
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Dave Rolsky <au...@urth.org>.
On Mon, 30 Oct 2000, G.W. Haywood wrote:
> If you can write Perl you can write C, there are onlya couple of dozen
> keywords. It's just that you're not so mollycoddled in C, you're much
> closer to the machine, and you have to plan further ahead (instead of
> waiting for the bang:). I prefer it.
I think you're forgetting about little things like regexes and such. Yes,
Perl and C share a lot of syntax, but there are many things you can do
easily in Perl that are brutal in C.
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by "G.W. Haywood" <ge...@www.jubileegroup.co.uk>.
Hi there,
On Mon, 30 Oct 2000, Greg Cope wrote:
> In theory there is no reason why this should not be translateable to C,
> it is quite small (in perl).
> However:
> a) I cannot do C (and translating this is beyond me as a learning
> exercise at the mo).
> b) Also waiting is a good idea till all the bugs are sorted. (I am sure
> there are more).
I think it's right to turn things like this into C. I'll help you
with it if you like, but I think you're right about waiting until the
design is stable before doing it.
If you can write Perl you can write C, there are onlya couple of dozen
keywords. It's just that you're not so mollycoddled in C, you're much
closer to the machine, and you have to plan further ahead (instead of
waiting for the bang:). I prefer it.
73,
Ged.
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Bill Moseley <mo...@hank.org>.
At 10:07 AM 10/30/00 +0000, Greg Cope wrote:
>Gunther Birznieks wrote:
>> This is an issue if your index.html requires the session id. So if you
>> direct to / you'll lose it. It's not bad if index.html is static, but it
>> could be generated via a handler or perhaps it's an index.cgi
>
>This should work (i think I test this case - cant remember) with just
>'/' as it just adds the '/' on - i,e you keep the session ID.
>
>My brain is stuck on the implications of this at the mo - I cannot see
>the "issue". The behavour appears wrong as the redirect is not right,
>yet it seems to come out in the wash .....
>
>Any ideas on what needs to be done - Gunther ? Bill ?
Hi Greg,
Sorry I haven't had a lot of time to think about it.
Again, my recommendation would be to not try and match against file names
in the PerlTransHandler, and rather split up the code to work in different
phases of the request.
Like in the Eagle book, you might use a trans handler to strip the session
off anything, but add the session later in the request. That way you can
use httpd.conf <location>, <directory>, and <files> sections to control
what gets a session added. But that's what I did in Apache::AuthCookieURL
and I'm having a hard time thinking out of the 'box' before my coffee.
Maybe fine tuning is all you need.
There might also be mod_rewrite or other trans modules that end up
requesting a different file name, so you have to consider if you want your
modules to look at the original request, or after it's been rewritten by
something like mod_rewrite.
Of course, DirectoryIndex can still be a problem since it's handled in a
subrequest. So maybe working only if $r->is_initial_req is true is an
issue, too.
GET /index.html HTTP/1.0
[Mon Oct 30 07:23:43 2000] [error] Initial:1 PerlTransHandler /index.html
[Mon Oct 30 07:23:43 2000] [error] Initial:1 PerlAccessHandler /index.html
[Mon Oct 30 07:23:43 2000] [error] Initial:1 PerlFixupHandler /index.html
GET / HTTP/1.0
[Mon Oct 30 07:24:32 2000] [error] Initial:1 PerlTransHandler /
[Mon Oct 30 07:24:32 2000] [error] Initial:1 PerlAccessHandler /
[Mon Oct 30 07:24:32 2000] [error] Initial:1 PerlFixupHandler /
[Mon Oct 30 07:24:32 2000] [error] Initial:0 PerlTransHandler /index.html
[Mon Oct 30 07:24:32 2000] [error] Initial:0 PerlAccessHandler /index.html
[Mon Oct 30 07:24:32 2000] [error] Initial:0 PerlFixupHandler /index.html
[Mon Oct 30 07:24:32 2000] [error] Initial:0 PerlTransHandler /index.html
[Mon Oct 30 07:24:32 2000] [error] Initial:0 PerlAccessHandler /index.html
[Mon Oct 30 07:24:32 2000] [error] Initial:0 PerlFixupHandler /index.html
Hey Apache! Why the extra set of sub requests???
Bill Moseley
mailto:moseley@hank.org
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Greg Cope <gr...@rubberplant.freeserve.co.uk>.
Gunther Birznieks wrote:
>
> At 01:31 AM 10/30/2000 +0000, Greg Cope wrote:
> >[...snip...]
> > >
> > > And don't forget about the use of DirectoryIndex:
> > > GET /index.html http/1.0
> > >
> > > HTTP/1.1 302 Found <<== here's your redirect
> > >
> > > Now this gets through:
> > > GET / http/1.0
> >
> >Hum ...
> >
> >Nice one - I had not tried this .... It took me a while to trap a '/'
> >request (it would go into an endless loop and blow out when the GET
> >request topped 4k, mostly full of session ID's).
> >
> >Not sure how to fix this - ideas anyone ?
> >
> >I do the following to trap a '/' style request - this is where I am
> >losing the /index.html (that's getting turned into a simple '/').
> >
> >if ($redirect !~ m#/$# && -d $r->lookup_uri($redirect)->filename) {
> > $redirect .= '/';
> > }
> >
> >Is this a major issue ? (as apache should if I am not mistaken turn that
> >back into an index.html or whatever is the directory index directive)
>
> This is an issue if your index.html requires the session id. So if you
> direct to / you'll lose it. It's not bad if index.html is static, but it
> could be generated via a handler or perhaps it's an index.cgi
This should work (i think I test this case - cant remember) with just
'/' as it just adds the '/' on - i,e you keep the session ID.
My brain is stuck on the implications of this at the mo - I cannot see
the "issue". The behavour appears wrong as the redirect is not right,
yet it seems to come out in the wash .....
Any ideas on what needs to be done - Gunther ? Bill ?
>
> >As apache has yet fully to do the URI translation I apear to be missing
> >this an assuming its a '/' on its own ?!?!
> >
> > >
> > > HTTP/1.1 200 OK
> > >
> > > I'm also unclear about excluding some files with $NON_MATCH. Perhaps I
> > > didn't set it up correctly.
> > >
> > > If the session is in the URL, and a browser uses relative links it will try
> > > to use that session for all links. So if $NON_MATCH is used to ignore
> > > .gif, for example, I see this:
> > >
> > > File does not exist:
> > > /usr/local/apache/htdocs/f0d960ddbbe1e82ca55ed2372447751e/apache_pb.gif
> >
> >I wondered on this for some time - as I use a new virtual host for
> >static content {gif|jpeg|js|css} files (with logging turned off).
> >
> >Err - on this point I am a plank and offer my apologies - a few '#' too
> >many and this functionality no longer works - whops ....
> >
> >In the meantime remove the hashes that
> >comment out the lines between 48 and 51 inclusive, also in the source is
> >a line:
> >
> >$NON_MATCH = '\.gif|\.jpeg|\.jpg'; # ignore images
> >
> >So if you only want gifs try:
> >
> >$NON_MATCH = '\.gif';
>
> So what is the logic here? You must always process an existing session id
> for images because they will be in the path, but you just shouldn't
> generate the session id if one does not exist for these mime types.
The module does a simple regex on DIR_MATCH and DECLINES if there is no
match.
If there is a match it then checks NON_MATCH and DECLINES if there is a
match here (i.e if we want to avid these hence NON_MATCH).
This was easier for me that to make a complex regex that matched this,
but not that etc ...
The logic is to not session these matches as they are not need.
If you keep your images on a different Vhost, or in a diferent dit (that
DIR_MATCH does not match and is hence ignored) then you do not need
this.
If you keep your images in the same place as the stuff you want to
session - then you may be interested.
It occurred to me whilist writing this module that there are manu
permutations (TMTOWTDI) and hence this was writen for the above combo.
Personnaly I do not use it.
> > > You might consider moving some of your code into other handlers later in
> > > the request and just let the transhandler extract out the session id. That
> > > way you can use <directory> and friends to configure what requires a
> > > session and what doesn't, and you can use PerlSetVars to control behavior
> > > section-by-section in httpd.conf.
> >
> >Gerald has already suggested this - I was thinking of controlling
> >directory access via the match variable. Why ? well perlset var gets
> >checked each request - performance wise a little nasty. This is however
> >due to most of my projects being a easy to split on a URI '/foo/' entry
> >i.e I know which parts of a URI need sessioning as it were.
> >
> >I was going to go for a perlset var as per Gerald Suggestions - but am
> >having secound thoughts - What do you|everyone think - using globals (a
> >la Apache::DBI style) is not as clean, but easy and fast whilst
> >perlsetvar is slower yet better to configure.
>
> I think you should use a hybrid. Globals for providing a server-wide
> DEFAULT and then PerlSetVar that overrides the global on a per-config
> basis. That way everyone wins.
I need to think about this further.
Gerald / anyone - would this be accpetable to you ?
Or does everything need to be a perlsetvar ?
>
> > > Hope some of this helps.
> >
> >Yup, you spotted a few bugs I had not seen - thanks
> >
> > >
> > > Have fun,
> >
> >Define fun ;-)
> >
> >I have found this one of the most rewarding coding exercises recently -
> >why:
> >
> >a) Its complex.
> >
> >b) Having all the mod_perl people have a go at breaking it (which they
> >have done ! )
> >
> >c) fixing it - which is has thus far been quite eaay (famous last words
> >;-)
> >
> >I'll be uploading a version 0.07 with the fixes outlined above.
>
> By the way, when the bugs are worked out of the Perl version, how difficult
> do you think it would be to convert to C?
>
> I think it's a good module in Perl if you are running your apps in Perl,
> but I have a client that uses Windows NT, Java servers, and mod_perl... So
> I'd like to have a module like this on the front-end server and then proxy
> the requests to back-end servers by setting a custom auth header that the
> backend servers would recognize.
>
> For a module like this, I'd prefer it not to be mod_perl because it seems
> like a fat thing to have on a front-end proxy server. On the other hand, I
> don't relish writing it in C unless there is a really solid Perl version
> that I can steal a well-tested algorithm from. :)
I was looking at this a week ago:
In thoery there is no reason why this should not be translateable to C,
it is quite small (in perl).
However:
a) I cannot do C (and translating this is beyond me as a learning
exercise at the mo).
b) Also waiting is a good idea till all the bugs are sorted. (I am sure
there are more).
Thanks
Greg
>
> Later,
> Gunther
Re: [ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Gunther Birznieks <gu...@extropia.com>.
At 01:31 AM 10/30/2000 +0000, Greg Cope wrote:
>[...snip...]
> >
> > And don't forget about the use of DirectoryIndex:
> > GET /index.html http/1.0
> >
> > HTTP/1.1 302 Found <<== here's your redirect
> >
> > Now this gets through:
> > GET / http/1.0
>
>Hum ...
>
>Nice one - I had not tried this .... It took me a while to trap a '/'
>request (it would go into an endless loop and blow out when the GET
>request topped 4k, mostly full of session ID's).
>
>Not sure how to fix this - ideas anyone ?
>
>I do the following to trap a '/' style request - this is where I am
>losing the /index.html (that's getting turned into a simple '/').
>
>if ($redirect !~ m#/$# && -d $r->lookup_uri($redirect)->filename) {
> $redirect .= '/';
> }
>
>Is this a major issue ? (as apache should if I am not mistaken turn that
>back into an index.html or whatever is the directory index directive)
This is an issue if your index.html requires the session id. So if you
direct to / you'll lose it. It's not bad if index.html is static, but it
could be generated via a handler or perhaps it's an index.cgi
>As apache has yet fully to do the URI translation I apear to be missing
>this an assuming its a '/' on its own ?!?!
>
> >
> > HTTP/1.1 200 OK
> >
> > I'm also unclear about excluding some files with $NON_MATCH. Perhaps I
> > didn't set it up correctly.
> >
> > If the session is in the URL, and a browser uses relative links it will try
> > to use that session for all links. So if $NON_MATCH is used to ignore
> > .gif, for example, I see this:
> >
> > File does not exist:
> > /usr/local/apache/htdocs/f0d960ddbbe1e82ca55ed2372447751e/apache_pb.gif
>
>I wondered on this for some time - as I use a new virtual host for
>static content {gif|jpeg|js|css} files (with logging turned off).
>
>Err - on this point I am a plank and offer my apologies - a few '#' too
>many and this functionality no longer works - whops ....
>
>In the meantime remove the hashes that
>comment out the lines between 48 and 51 inclusive, also in the source is
>a line:
>
>$NON_MATCH = '\.gif|\.jpeg|\.jpg'; # ignore images
>
>So if you only want gifs try:
>
>$NON_MATCH = '\.gif';
So what is the logic here? You must always process an existing session id
for images because they will be in the path, but you just shouldn't
generate the session id if one does not exist for these mime types.
> >
> > You might consider moving some of your code into other handlers later in
> > the request and just let the transhandler extract out the session id. That
> > way you can use <directory> and friends to configure what requires a
> > session and what doesn't, and you can use PerlSetVars to control behavior
> > section-by-section in httpd.conf.
>
>Gerald has already suggested this - I was thinking of controlling
>directory access via the match variable. Why ? well perlset var gets
>checked each request - performance wise a little nasty. This is however
>due to most of my projects being a easy to split on a URI '/foo/' entry
>i.e I know which parts of a URI need sessioning as it were.
>
>I was going to go for a perlset var as per Gerald Suggestions - but am
>having secound thoughts - What do you|everyone think - using globals (a
>la Apache::DBI style) is not as clean, but easy and fast whilst
>perlsetvar is slower yet better to configure.
I think you should use a hybrid. Globals for providing a server-wide
DEFAULT and then PerlSetVar that overrides the global on a per-config
basis. That way everyone wins.
> > Hope some of this helps.
>
>Yup, you spotted a few bugs I had not seen - thanks
>
> >
> > Have fun,
>
>Define fun ;-)
>
>I have found this one of the most rewarding coding exercises recently -
>why:
>
>a) Its complex.
>
>b) Having all the mod_perl people have a go at breaking it (which they
>have done ! )
>
>c) fixing it - which is has thus far been quite eaay (famous last words
>;-)
>
>I'll be uploading a version 0.07 with the fixes outlined above.
By the way, when the bugs are worked out of the Perl version, how difficult
do you think it would be to convert to C?
I think it's a good module in Perl if you are running your apps in Perl,
but I have a client that uses Windows NT, Java servers, and mod_perl... So
I'd like to have a module like this on the front-end server and then proxy
the requests to back-end servers by setting a custom auth header that the
backend servers would recognize.
For a module like this, I'd prefer it not to be mod_perl because it seems
like a fat thing to have on a front-end proxy server. On the other hand, I
don't relish writing it in C unless there is a really solid Perl version
that I can steal a well-tested algorithm from. :)
Later,
Gunther
[ ANNOUNCE ] Apache::SessionManager-0.07
Posted by Greg Cope <gr...@rubberplant.freeserve.co.uk>.
Bill Moseley wrote:
>
> At 05:24 PM 10/29/00 +0000, Greg Cope wrote:
> >Announcing Apache::SessionManager.
>
> Hi Greg,
>
> Here's a couple of other comments.
I should have mentioned that this was my first bit of public code - and
to be gentle ..
>
> Don't forget to keep track of args on redirects:
>
> GET /a5cc39a8c110566e41b5b8efafc2a055/index.html/abc/123?query=abc http/1.0
> Cookie: SESSION=cb74254c1de96365e91fa6d6d481f952
>
> HTTP/1.1 302 Found
> Date: Sun, 29 Oct 2000 18:28:54 GMT
> Server: Apache/1.3.14 (Unix) mod_perl/1.24_01
> Location: /index.html/abc/123 <<<<=== lost the args here.
I thought I had this covered ages ago. ... I've just tried this on my
set up and I do not lose the args e.g.
Netscrape 4.75 on Linux / Redhat
switch cookies off in preferences - redirect on:
get Cart/cat?foo=bar
redirect to:
get /{insert session id here}/Cart/cat?foo=bar
But I was not checking COOKIE_CHECK
A few minutes later that should be fixed ...
I have not being doing a COOKIE_CHECK style redirect against a
foo.html?arg=bar style get request - all mine have been simple HTML
pages.
Thanks.
>
> And don't forget about the use of DirectoryIndex:
> GET /index.html http/1.0
>
> HTTP/1.1 302 Found <<== here's your redirect
>
> Now this gets through:
> GET / http/1.0
Hum ...
Nice one - I had not tried this .... It took me a while to trap a '/'
request (it would go into an endless loop and blow out when the GET
request topped 4k, mostly full of session ID's).
Not sure how to fix this - ideas anyone ?
I do the following to trap a '/' style request - this is where I am
losing the /index.html (that's getting turned into a simple '/').
if ($redirect !~ m#/$# && -d $r->lookup_uri($redirect)->filename) {
$redirect .= '/';
}
Is this a major issue ? (as apache should if I am not mistaken turn that
back into an index.html or whatever is the directory index directive)
As apache has yet fully to do the URI translation I apear to be missing
this an assuming its a '/' on its own ?!?!
>
> HTTP/1.1 200 OK
>
> I'm also unclear about excluding some files with $NON_MATCH. Perhaps I
> didn't set it up correctly.
>
> If the session is in the URL, and a browser uses relative links it will try
> to use that session for all links. So if $NON_MATCH is used to ignore
> .gif, for example, I see this:
>
> File does not exist:
> /usr/local/apache/htdocs/f0d960ddbbe1e82ca55ed2372447751e/apache_pb.gif
I wondered on this for some time - as I use a new virtual host for
static content {gif|jpeg|js|css} files (with logging turned off).
Err - on this point I am a plank and offer my apologies - a few '#' too
many and this functionality no longer works - whops ....
In the meantime remove the hashes that
comment out the lines between 48 and 51 inclusive, also in the source is
a line:
$NON_MATCH = '\.gif|\.jpeg|\.jpg'; # ignore images
So if you only want gifs try:
$NON_MATCH = '\.gif';
>
> You might consider moving some of your code into other handlers later in
> the request and just let the transhandler extract out the session id. That
> way you can use <directory> and friends to configure what requires a
> session and what doesn't, and you can use PerlSetVars to control behavior
> section-by-section in httpd.conf.
Gerald has already suggested this - I was thinking of controlling
directory access via the match variable. Why ? well perlset var gets
checked each request - performance wise a little nasty. This is however
due to most of my projects being a easy to split on a URI '/foo/' entry
i.e I know which parts of a URI need sessioning as it were.
I was going to go for a perlset var as per Gerald Suggestions - but am
having secound thoughts - What do you|everyone think - using globals (a
la Apache::DBI style) is not as clean, but easy and fast whilst
perlsetvar is slower yet better to configure.
> Hope some of this helps.
Yup, you spotted a few bugs I had not seen - thanks
>
> Have fun,
Define fun ;-)
I have found this one of the most rewarding coding exercises recently -
why:
a) Its complex.
b) Having all the mod_perl people have a go at breaking it (which they
have done ! )
c) fixing it - which is has thus far been quite eaay (famous last words
;-)
I'll be uploading a version 0.07 with the fixes outlined above.
Thanks Bill, much appreciated as you have tested it in ways that I had
not thought of (and I've tried a few), hopefull v 0.07 should fix most
of the above.
Thanks again.
Greg
>
> Bill Moseley
> mailto:moseley@hank.org
Re: [ ANNOUNCE ] Apache::SessionManager-0.06
Posted by Bill Moseley <mo...@hank.org>.
At 05:24 PM 10/29/00 +0000, Greg Cope wrote:
>Announcing Apache::SessionManager.
Hi Greg,
Here's a couple of other comments.
Don't forget to keep track of args on redirects:
GET /a5cc39a8c110566e41b5b8efafc2a055/index.html/abc/123?query=abc http/1.0
Cookie: SESSION=cb74254c1de96365e91fa6d6d481f952
HTTP/1.1 302 Found
Date: Sun, 29 Oct 2000 18:28:54 GMT
Server: Apache/1.3.14 (Unix) mod_perl/1.24_01
Location: /index.html/abc/123 <<<<=== lost the args here.
And don't forget about the use of DirectoryIndex:
GET /index.html http/1.0
HTTP/1.1 302 Found <<== here's your redirect
Now this gets through:
GET / http/1.0
HTTP/1.1 200 OK
I'm also unclear about excluding some files with $NON_MATCH. Perhaps I
didn't set it up correctly.
If the session is in the URL, and a browser uses relative links it will try
to use that session for all links. So if $NON_MATCH is used to ignore
.gif, for example, I see this:
File does not exist:
/usr/local/apache/htdocs/f0d960ddbbe1e82ca55ed2372447751e/apache_pb.gif
You might consider moving some of your code into other handlers later in
the request and just let the transhandler extract out the session id. That
way you can use <directory> and friends to configure what requires a
session and what doesn't, and you can use PerlSetVars to control behavior
section-by-section in httpd.conf.
Hope some of this helps.
Have fun,
Bill Moseley
mailto:moseley@hank.org