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
