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
