caudium-devel AT caudium.net
Caudium Developer mailing list.

Re: PATH_INFO (was: Re: [caudium-devel] Odd problem with caudium)


chronological Thread 
  • 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.

§