- From: Marek Habersack <grendel AT caudium.net>
- To: caudium-devel AT caudium.net
- Subject: Re: PATH_INFO (was: Re: [caudium-devel] Odd problem with caudium)
- Date: Tue, 21 Feb 2006 12:28:16 +0100
- Organization: I just...
On Tue, Feb 21, 2006 at 09:40:32AM +0100, Bertrand LUPART scribbled:
>
>
On 20 févr. 06, at 21:01, Marek Habersack wrote:
>
>On Mon, Feb 20, 2006 at 02:50:38PM +0100, Bertrand LUPART scribbled:
>
>>Hey Marek,
>
>>
>
>>> Here I was thinking that Caudium can no longer surprise me with
>
>>>something
>
>>>funny, and yet... I've got a site running caudium hidden behind a
>
>>>squid
>
>>>instance. The site uses gsession, which works just fine for the /
>
>>>URL
>
>>>_only_. For other urls within the site, gsession does create its id-
>
>>>>misc
>
>>>stuff but just after that everything is somehow wiped out from id-
>
>>>>misc.
>
>>> Has anybody observed such behavior too? Any ideas on what it
>
>>>might be?
>
>>
>
>>Session creation in gsession is done via MODULE_FIRST right?
>
>Yep
>
>
>
>>I had some problems last week with a MODULE_FIRST of my own not being
>
>>called because the Filesystem module was called first (i think that
>
>>should be reverse order, while i'm finally not totally sure).
>
>As far as I remember, the modules are called in the random order
>
>unless you
>
>set the priority.
>
>
The filesystem module is MODULE_LOCATION.
>
>
As Martin said and according to the flow chart on the Caudium website
>
(http://caudium.net/server/docs/modules.rxml), MODULE_FIRST should be
>
called (in random order) before MODULE_LOCATION (they are).
Yeah, and within the class (like Martin pointed out) they are kept in a
mapping, which means they're effectively in random order - that is unless
you move any of them to a higher priority (within the priority class they're
random as well). I think we should do something about the randomization -
the behavior should be predictable, be it even alphabetic.
>
>
>>I did not dig further yet (used a MODULE_PRECACHE). That's maybe
>
>>related to your problem.
>
>It turned out to be the PATH_INFO module that started to block
>
>gsessions all
>
>of the sudden... Very frustrating.
>
>
You ran into the very same problem than me.
>
>
Loaded the gsession module, and according to the CIF path resolver,
>
gsession is called when my own MODULE_FIRST is called, too.
For me it _always_ got called for implicit urls (like site.com/stuff/) but
explicit urls (site.com/stuff/index.html) weren't ever passed to gsession.
Shouldn't we just make the whole stuff into a chain of filters instead?
>
They aren't called when you request a file that exists on the
>
filesystem. Try a directory (/, /images/ …) or a file that doesn't
>
exists (/favicon.ico) and it works.
yeah...
>
Unload PATH_INFO and everything is fine.
>
Well, that's not fine at all because i'm planning to use PATH_INFO in
>
the very near future :)
>
>
After having a quick look at pathinfo.pike, it seems that first_try()
>
returns 1 when a file exists.
>
My guess is something is wrong here (but today is meeting day).
There are a lot of things that are wrong about 1.4+ alas :(
marek
Attachment:
signature.asc
Description: Digital signature
Archive powered by MhonArc 2.6.10.