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:[EMAIL PROTECTED]
