Ok, here is some more data to ponder.

Scenario 1:
MidgardFavorFiles = On
httpUrl ="/music/"
midgardPage "/music"
filePath  /our/site/music

In this scenario apache will serve out a filesystem index page
instead of a midgard page. this is expected.
If there is no filesystem page there is no midgard fallback, ie there
is no midgard page being served at all in this scenario. It is just like turning off
MidgardEngine.
In my case directory listing are blocked so I get a nasty message:

:::You don't have permission to access /music/ on this server.:::


now if there is no name conflict then yes midgard will serve out
it's page.



Scenario 1:
MidgardFavorFiles = Off
httpUrl ="/music/"
midgardPage "/music"
filePath  /our/site/music


In this scenario  midgard will win every name conflict as expected.
The problem here is that again there is no fallback at all.
midgard will not check the filesystem at all it it is not found in the database.
on this site I have phpBB running in  "/phpBB/"
in this scenario a request to
http://www.hitlist.com/phpBB/ will only show you the midgard
pageroot with it's  style applied.


THE OLD WAY:


In the old mod_midgard there was a database check first then
a fallback to the filesystem. There seems to be no fallback taking  place
wether MidgardFavorFiles is On or Off.

sigh.




Vincent Stoessel wrote:

> Emiliano wrote:
> 
>> Vincent Stoessel wrote:
>>
>>
>>>> But no message like "Midgard: serving page" or "Midgard: serving blob"?
>>>>
>>> the word "blob" does not appear in my error log, (OK, I did just clear
>>> that log. i will keeping checking)
>>>
>>
>> When LogLevel is set to debug, one of these two messages must appear or
>> Midgard will have decided not to serve the request. It will log the
>> cached page it is serving. Any messages between the translate_handler
>> line and this message (inclusive) are interesting to me.
>>
>>
>>> compliled the new version : still says it's trying to connect to 
>>> localhost.
>>> I used -Smydbserver
>>>
>>
>> Ah, that was only in display. I've fixed it.
> 
> 
> 
> Yeah, it displays correctly now:
> 
> test/pageresolve  -Smedusa   -hwww.hitlist.com -u/images/fp9.jpg
> Connecting to mysql://midgard:midgard@correctHostName/midgard
> Resolving host: http://www.hitlist.com:80/images/fp9.jpg
> Host found: 10
> Resolving page: http://www.hitlist.com:80/images/fp9.jpg
> RESULT: No page or blob record found
> 
> 
> 
>>
>> This was the line I was looking for. Page 88 is your rootpage, then?
> 
> 
> 
> 
> yes it is.
> 
> 
>>
>> For the life of me, I can't find what causes this. I know how it gets to
>> the root page: at the start of the uri parse it will assume the rootpage
>> is found, but the first non-match against the uri should invalidate
>> that. Looking into it.
>>
>> Emile
> 
> 
> 
> 
> Cool, I appreciate it.
> 
> 
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
> 
> 
> 


-- 
Vincent Stoessel [EMAIL PROTECTED]
Java Linux Apache Mysql Php (JLAMP) Engineer
(301) 362-1750 Mobile (410) 419-8588
AIM, MSN: xaymaca2020 , Yahoo Messenger: vks_jamaica


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to