lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi, Nicolas,

I am crossposting this to the Kepler developers list, we like to keep the noise down in the regular Lua list. :-)

On Wed, Nov 4, 2009 at 9:25 AM, Nicolas <nicolas@net-core.org> wrote:
Hi,

First I have found what looks like a bug to me, which surprises
me a lot:

There was an error in the specified application. The full error message follows:

/usr/local/share/lua/5.1//wsapi/common.lua:393: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
 
The initialization is done at line 431, so it looks like you are hitting a strange corner case. Did you change anything in wsapi.fcgi?



Secondly I am having an other problem, in my setup with apache and fcgi
let's say I make an app for the url /lua/foo.ws
It works fine and my app is called.
Now if I try to access it as /lua/foo.ws/whatever, if I am reading things right it
should still work (otherwise Orbit dispatchers becomes quite useless no ?)

It should.
 
The problem is that in normalize_paths() in wsapi.common there are three lines:
  if not filename or filename == "" then
     filename = wsapi_env.PATH_TRANSLATED
     if filename == "" then filename = wsapi_env.SCRIPT_FILENAME end

"filename" parameter comes from the wsapi.fcgi launcher which sets it as ""
thus the code enters the if and replaced filename with PATH_TRANSLATED which
does not contain the app name.
In my example (/lua/foo.ws/whatever) I have:
PATH_TRANSLATED=/var/www/test.netpim.info/htdocs/whatever
SCRIPT_FILENAME=/var/www/test.netpim.info/htdocs/lua/foo.ws



Apache shouldn't be messing with PATH_TRANSLATED in this way, these web servers and their inconsistent behavior drive me up the wall. I am going to fire up an Apache and test, but is there anything different in your Apache config? I used grab SCRIPT_FILENAME first, but an user discovered that Apache on OSX had a problem with that in some cases, so I switched. I should probably give up on autodetecting how the particular webserver works and add an option to wsapi.fcgi...
 
I resolved my problem by forcing "filename = wsapi_env.SCRIPT_FILENAME" but
it looks like a bad fix to me.
Any ideas ?

Thanks

Thanks for the report,
Fabio Mascarenhas