Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Guenter Knauf

On 10.04.2013 23:21, Guenter Knauf wrote:

On 10.04.2013 23:01, fua...@apache.org wrote:

Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149

URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...



ok, onward with some more testing .

now on r:exists_config_define(string) ...

this script:

function handle(r)
  r.content_type = text/plain

  if r:exists_config_define(SSL) then
r:puts(httpd was probably run with -DSSL, or it was defined in the 
configuration)

  end
end

results in:

Error!

sys:/www/tstlua/not_working/cfgdefine.lua:4: calling 
'exists_config_define' on bad self (string expected, got userdata)


Gün.






Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Daniel Gruno
On 04/19/2013 02:48 PM, Guenter Knauf wrote:
 On 10.04.2013 23:21, Guenter Knauf wrote:
 On 10.04.2013 23:01, fua...@apache.org wrote:
 Author: fuankg
 Date: Wed Apr 10 21:01:51 2013
 New Revision: 149

 URL: http://svn.apache.org/r149
 Log:
 Put this backport for now on hold to get some more
 time for testing ...
 
 ok, onward with some more testing .
 now on r:exists_config_define(string) ...
 
 this script:
 
 function handle(r)
   r.content_type = text/plain
 
   if r:exists_config_define(SSL) then
 r:puts(httpd was probably run with -DSSL, or it was defined in the
 configuration)
   end
 end
 
 results in:
 
 Error!
 
 sys:/www/tstlua/not_working/cfgdefine.lua:4: calling
 'exists_config_define' on bad self (string expected, got userdata)
 
 Gün.
 
 
 
 
Yeah, that should be r.exists_config_define.
Do you want me to just fix the docs, or should we turn it into
r:exists_config_define for the sake of consistency?

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Guenter Knauf

On 10.04.2013 23:21, Guenter Knauf wrote:

On 10.04.2013 23:01, fua...@apache.org wrote:

Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149

URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...



ok, onward with some more testing .

now on r:strcmp_match(string, pattern) ...

this script:

function handle(r)
  r.content_type = text/plain

  local match = r:strcmp_match(foobar.com, foo*.com)
  if match then
r:puts(foobar.com matches foo*.com)
  end
end

results in:

Error!

sys:/www/tstlua/not_working/strcmpmatch.lua:4: calling 'strcmp_match' on 
bad self (string expected, got userdata)


Gün.








Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Daniel Gruno
On 04/19/2013 03:02 PM, Guenter Knauf wrote:
 On 10.04.2013 23:21, Guenter Knauf wrote:
 On 10.04.2013 23:01, fua...@apache.org wrote:
 Author: fuankg
 Date: Wed Apr 10 21:01:51 2013
 New Revision: 149

 URL: http://svn.apache.org/r149
 Log:
 Put this backport for now on hold to get some more
 time for testing ...
 
 ok, onward with some more testing .
 now on r:strcmp_match(string, pattern) ...
 
 this script:
 
 function handle(r)
   r.content_type = text/plain
 
   local match = r:strcmp_match(foobar.com, foo*.com)
   if match then
 r:puts(foobar.com matches foo*.com)
   end
 end
 
 results in:
 
 Error!
 
 sys:/www/tstlua/not_working/strcmpmatch.lua:4: calling 'strcmp_match' on
 bad self (string expected, got userdata)
 
 Gün.
 
 
Same reply there, it's because some functions require the request_rec
struct, while others don't, that may have thrown me off in the
documentation. We could either fix the docs so it's r. in the right
places instead of r:, but what we could also do is just silently discard
the first argument, so we'll have r: across the board.

With regards,
Daniel.



Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Guenter Knauf

On 19.04.2013 14:53, Daniel Gruno wrote:

Do you want me to just fix the docs, or should we turn it into
r:exists_config_define for the sake of consistency?

ok, the other one was r.module_info(module_name);
so for now since we dont have yet consistency I'd say fix the docs ;-)

But would be great to hear some more oppinions from others regarding 
this ...


Gün.





Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Guenter Knauf

Hi Daniel,
On 19.04.2013 14:53, Daniel Gruno wrote:

Yeah, that should be r.exists_config_define.

ok, new test:

function call_exists_config_define(r, text)
  if r.exists_config_define(text) then
r:puts(httpd was probably run with -D .. text .. , or it was 
defined in the configuration.\n)

  end
end

function handle(r)
  r.content_type = text/plain

  local text1 = Everything
  local text2 = seems
  local text3 = here
  local text4 = defined!

  call_exists_config_define(r, text1)
  call_exists_config_define(r, text2)
  call_exists_config_define(r, text3)
  call_exists_config_define(r, text4)

  r:puts( (\nPowered by %s on %s\n):format(_VERSION, r.banner) )
end

result:
httpd was probably run with -DEverything, or it was defined in the 
configuration.

httpd was probably run with -Dseems, or it was defined in the configuration.
httpd was probably run with -Dhere, or it was defined in the configuration.
httpd was probably run with -Ddefined!, or it was defined in the 
configuration.



Do you want me to just fix the docs, or should we turn it into
r:exists_config_define for the sake of consistency?

hmm, not sure; what did we do with the other one recently?

Gün.





Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Daniel Gruno
On 04/19/2013 04:01 PM, Guenter Knauf wrote:
 Hi Daniel,
 On 19.04.2013 14:53, Daniel Gruno wrote:
 Yeah, that should be r.exists_config_define.
 ok, new test:
 
 function call_exists_config_define(r, text)
   if r.exists_config_define(text) then
 r:puts(httpd was probably run with -D .. text .. , or it was
 defined in the configuration.\n)
   end
 end
 
 function handle(r)
   r.content_type = text/plain
 
   local text1 = Everything
   local text2 = seems
   local text3 = here
   local text4 = defined!
 
   call_exists_config_define(r, text1)
   call_exists_config_define(r, text2)
   call_exists_config_define(r, text3)
   call_exists_config_define(r, text4)
 
   r:puts( (\nPowered by %s on %s\n):format(_VERSION, r.banner) )
 end
 
 result:
 httpd was probably run with -DEverything, or it was defined in the
 configuration.
 httpd was probably run with -Dseems, or it was defined in the
 configuration.
 httpd was probably run with -Dhere, or it was defined in the configuration.
 httpd was probably run with -Ddefined!, or it was defined in the
 configuration.
 
 Do you want me to just fix the docs, or should we turn it into
 r:exists_config_define for the sake of consistency?
 hmm, not sure; what did we do with the other one recently?
 
 Gün.
 
 
 
See r1469844

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Guenter Knauf

Hi Daniel,
On 19.04.2013 16:29, Daniel Gruno wrote:

See r1469844

yeah, thought as much when I printed the result which showed 0 or 1;
but I had to leave so couldnt self dig into the code ATM ...

Gün.






Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Guenter Knauf

Daniel,
On 19.04.2013 18:19, Guenter Knauf wrote:

On 19.04.2013 16:29, Daniel Gruno wrote:

See r1469844

yeah, thought as much when I printed the result which showed 0 or 1;
but I had to leave so couldnt self dig into the code ATM ...
wouldnt it be even more uselful to have instead a 
r.get_config_define(string) so that we could also get the value of the 
define if there's any?


Gün.




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-19 Thread Daniel Gruno
On 04/19/2013 06:25 PM, Guenter Knauf wrote:
 Daniel,
 On 19.04.2013 18:19, Guenter Knauf wrote:
 On 19.04.2013 16:29, Daniel Gruno wrote:
 See r1469844
 yeah, thought as much when I printed the result which showed 0 or 1;
 but I had to leave so couldnt self dig into the code ATM ...
 wouldnt it be even more uselful to have instead a
 r.get_config_define(string) so that we could also get the value of the
 define if there's any?
 
 Gün.
 
 
Yes, it would, but it's not as easy to wrap around as
exists_config_define ;)
I'll take a look at replacing the function today, hopefully I'll get
somewhere.

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-14 Thread Guenter Knauf

On 14.04.2013 07:28, Daniel Gruno wrote:

ah yes, I made a rookie mistake there ;)
I'll fix up the docs accordingly.
thanks; while on that can you perhaps also mention the default of 25 
regex matches, and my change for optional flags?

matches, err = r:regex(string, pattern [,flags])

where flags are:
http://ci.apache.org/projects/httpd/trunk/doxygen/ap__regex_8h.html#a1b9b918a53bffc54baadd6169159e2e4

Gün.




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-14 Thread Guenter Knauf

On 14.04.2013 08:35, Guenter Knauf wrote:

On 14.04.2013 07:28, Daniel Gruno wrote:

ah yes, I made a rookie mistake there ;)
I'll fix up the docs accordingly.

thanks; while on that can you perhaps also mention the default of 25
regex matches, and my change for optional flags?
matches, err = r:regex(string, pattern [,flags])

where flags are:
http://ci.apache.org/projects/httpd/trunk/doxygen/ap__regex_8h.html#a1b9b918a53bffc54baadd6169159e2e4

more precise:
cflags 	Bitwise OR of AP_REG_* flags (ICASE and NEWLINE supported, other 
flags are ignored)

#define AP_REG_ICASE   0x01
#define AP_REG_NEWLINE 0x02

(I've not yet tested the AP_REG_NEWLINE flag)

Gün.





Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-13 Thread Daniel Gruno
On 04/12/2013 10:42 PM, Guenter Knauf wrote:
 On 10.04.2013 23:21, Guenter Knauf wrote:
 On 10.04.2013 23:01, fua...@apache.org wrote:
 Author: fuankg
 Date: Wed Apr 10 21:01:51 2013
 New Revision: 149

 URL: http://svn.apache.org/r149
 Log:
 Put this backport for now on hold to get some more
 time for testing ...
 
 ok, onward with some more testing .
 now on r:regex() ...
 
 1) the sample in the docs is completely wrong ...
 1.1) the docu has r:regex(string, pattern) but current code implements
 r:regex(pattern, string); I will change this in the code soon since I it
 looks more Lua-like for me what is in the docs since all other Lua match
 functions also have parameters in the order (string, pattern)
 1.2) the pattern foo (%w+) (%S*) doesnt work for me; it looks more
 like a pattern for string.match(); instead a valid pattern for r:regex()
 would be f.e. foo (\\w+) (\\a+); backslash must be escaped in a Lua
 string
 
 2) r:regex() crashes the server if more than AP_MAX_REG_MATCH matches
 are found; this is because we still get the real number of matches in
 regex.re_nsub although passing in AP_MAX_REG_MATCH:
 rv = ap_regexec(regex, source, AP_MAX_REG_MATCH, matches, 0);
 
 when I add:
 
 if (regex.re_nsub  AP_MAX_REG_MATCH) {
 ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
   regex returned %d matches; allowed %d.,
   regex.re_nsub, AP_MAX_REG_MATCH);
 return 2;
 }
 
 and test with a 20 match regex, I get this in the log:
 regex returned 20 matches; allowed 10.
 
 The docu of regexec() gives no hints about how to retrieve the real
 number of matches stored:
 http://ci.apache.org/projects/httpd/trunk/doxygen/ap__regex_8h.html
 and I've not yet digged into the code; but we need to make sure that the
 following loop doesnt loop over AP_MAX_REG_MATCH:
 for (i = 0; i = regex.re_nsub; i++) {
 
 BTW. what is the reason for limiting AP_MAX_REG_MATCH to 10 in httpd.h ?
 
 Gün.
 
 
I think the reason for limiting it to 10 is legacy stuff, so that's what
I've complied with.

Docs fixed, ordering of arguments likewise, and r.banner as well as
r.port are now just values, not functions.

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-13 Thread Daniel Gruno
On 04/12/2013 10:01 PM, Gregg Smith wrote:
 On 4/12/2013 10:43 AM, Guenter Knauf wrote:
 I know; but I dont know if Gregg did a release or debug build;
 I've heard a couple of times in the past that folks were not able to
 re-create crash with debug builds but which happen with release builds;
 that could f.e. explain why Daniel doesnt see the issue with his debug
 build.
 
 This seems to be the case.
 The attached lua script crashes on a Release build, but succeeds on a
 Debug build.
 
 Regards,
 
 Gregg
 
I've made some workarounds so it shouldn't crash with that script on
release builds any more.

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-13 Thread Guenter Knauf

HI Daniel,
On 13.04.2013 08:47, Daniel Gruno wrote:

I think the reason for limiting it to 10 is legacy stuff, so that's what
I've complied with.
but thats way to less for doing something useful; therefore I've 
decoupled mod_lua from AP_MAX_REG_MATCH, added an own macro 
MODLUA_MAX_REG_MATCH, made this overwriteable with CFALGS and bumped the 
default to 25;
hopefully a config hacker adds an option so that this can be 
specified/modified ...



Docs fixed,

well, the sample regex is still wrong - backslash must be escaped:
- local matches = r:regex(foo bar baz, foo (\w+) (\S*))
+ local matches = r:regex(foo bar baz, foo (\\w+) (\\S*))



ordering of arguments likewise, and r.banner as well as
r.port are now just values, not functions.

great!

Your fix with commit r1467557 should it somehow return more matches 
than we have allocated was my 1st patch too in order to see if that 
avoids the crash (and sure it does); but IMO its really bad to silently 
discard matches and give the user no idea why ...
we should here think of a normal user who works on a regex pattern, and 
then wonders (and bashing head against the wall) why his pattern gets 
accepted without error, but he still gets less matches than expected; 
therefore I've changed the code to bail out early after the regcomp call 
when we know already that the pattern has more matches than allowed, and 
instead return with an error explaining this. So now you can call 
r:regex() like:

local matches, err = r:regex(foo bar baz, foo (\\w+) (\\S*))
if err then
  r:puts(err)
else
  ...

attached some examples to verify my recent changes.

Gün.


tstlua.7z
Description: Binary data


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-13 Thread Daniel Gruno
On 04/14/2013 07:17 AM, Guenter Knauf wrote:
 HI Daniel,
 On 13.04.2013 08:47, Daniel Gruno wrote:
 I think the reason for limiting it to 10 is legacy stuff, so that's what
 I've complied with.
 but thats way to less for doing something useful; therefore I've
 decoupled mod_lua from AP_MAX_REG_MATCH, added an own macro
 MODLUA_MAX_REG_MATCH, made this overwriteable with CFALGS and bumped the
 default to 25;
 hopefully a config hacker adds an option so that this can be
 specified/modified ...
 
 Docs fixed,
 well, the sample regex is still wrong - backslash must be escaped:
 - local matches = r:regex(foo bar baz, foo (\w+) (\S*))
 + local matches = r:regex(foo bar baz, foo (\\w+) (\\S*))
 
 
 ordering of arguments likewise, and r.banner as well as
 r.port are now just values, not functions.
 great!
 
 Your fix with commit r1467557 should it somehow return more matches
 than we have allocated was my 1st patch too in order to see if that
 avoids the crash (and sure it does); but IMO its really bad to silently
 discard matches and give the user no idea why ...
 we should here think of a normal user who works on a regex pattern, and
 then wonders (and bashing head against the wall) why his pattern gets
 accepted without error, but he still gets less matches than expected;
 therefore I've changed the code to bail out early after the regcomp call
 when we know already that the pattern has more matches than allowed, and
 instead return with an error explaining this. So now you can call
 r:regex() like:
 local matches, err = r:regex(foo bar baz, foo (\\w+) (\\S*))
 if err then
   r:puts(err)
 else
   ...
 
 attached some examples to verify my recent changes.
 
 Gün.
ah yes, I made a rookie mistake there ;)
I'll fix up the docs accordingly.

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread Daniel Gruno
On 04/11/2013 11:24 PM, Gregg Smith wrote:
 On 4/11/2013 9:05 AM, Daniel Gruno wrote:
 I just tried the script you attached on my Windows box, as well as the
 original LuaRoot + LuaMapHandler problem, and I can't find anything
 wrong with it, it works flawlessly with httpd 2.4.4 + mod_lua from trunk
 (using Lua 5.1.4). There appears to be nothing in the code that triggers
 it (go look yourself, I can't find anything), so I'm just about to chalk
 it up to Windows (or possibly Lua for Windows) just acting weird for
 some people.

 So, to sum up; I can't reproduce either of the crashes on my Windows 7
 machine :(
 
 Ok, so it's not Lua 5.1.5 or 5.2.2 as I just tried with 5.1.4 and
 trunk's mod_lua of r1466822
 I've ruled out the UAC in Vista, run from console vs. Windows Service.
 
 So I'm curious, what did you build with (vc10/mingw/etc)?
 
 Regards,
 
 Gregg
I built it with VC11 in debug mode using Visual Studio Express 2012
(took a bloody long while to get it to build ;) ). I also tried the VC10
version from Apachelounge, and it too worked like a charm, so I'm
stumped as to what would/could cause the error you reported. If you have
some more info, or could try to reproduce it again with a backtrace, I'd
appreciate it, because I can't seem to find anything bad in the code -
the pool gets passed on as it should, so it shouldn't suddenly turn into
a null pointer at any point in the code :(.

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread William A. Rowe Jr.
On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf fua...@apache.org wrote:

 I've now tested on Windows, and I can see all previously mentioned 
 issues there too; in addition the attached script which works fine on 
 NetWare crashes the Windows httpd ...

Backtrace, please?

A strange idea, but did you happen to build lua libs with the
identical Visual Studio version and mode as httpd (both debug,
or both release builds?)

If you are mixing two different msvcrt flavors (debug/release,
or studio10/studio12) and the lua lib is performing any sort of
alloc/free of the resources allocated by httpd, this would be
a typical symptom.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread Guenter Knauf

Hi Bill,
On 12.04.2013 18:37, William A. Rowe Jr. wrote:

On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf fua...@apache.org wrote:


I've now tested on Windows, and I can see all previously mentioned
issues there too; in addition the attached script which works fine on
NetWare crashes the Windows httpd ...


Backtrace, please?

I did test with a build from Gregg;
I'm in process of rebuilding my dev box, and its not yet ready to do so ...


A strange idea, but did you happen to build lua libs with the
identical Visual Studio version and mode as httpd (both debug,
or both release builds?)

I'm sure he did.


If you are mixing two different msvcrt flavors (debug/release,
or studio10/studio12) and the lua lib is performing any sort of
alloc/free of the resources allocated by httpd, this would be
a typical symptom.

I know; but I dont know if Gregg did a release or debug build;
I've heard a couple of times in the past that folks were not able to 
re-create crash with debug builds but which happen with release builds;
that could f.e. explain why Daniel doesnt see the issue with his debug 
build.


Gün.





Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread Guenter Knauf

On 11.04.2013 15:06, Daniel Gruno wrote:

On 04/11/2013 02:36 PM, Guenter Knauf wrote:

oh, and some more questions:
whats the benefit of having banner(), port() and started() as functions
(or methods)?
isnt it fine accessing these like f.e. r.filename?
r:put(r.banner) would be even shorter than r:put(r:banner()) ...

and why is it:
r.module_info(module_name)
and not:
r:module_info(module_name)


I'll look into adding them as variables instead :)

ok.


r.module_info is because it doesn't need the request_rec object to get
module information (foo:bar(baz) is short for foo.bar(foo, baz) ).

ok.


I admit, it can be a bit confusing, and perhaps we should consider
turning it into r:module_info for the sake of conformity, but I don't
consider it a bug or anything that would stall a backport.
I did ask a question as newbie, hoping you could quickly shed light into 
it, and you did; just wanted to be sure that it wasnt a thingy by 
acciedent ...

I did not consider this as a bug either.

Gün.



Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread Gregg Smith

On 4/12/2013 10:43 AM, Guenter Knauf wrote:

Hi Bill,
On 12.04.2013 18:37, William A. Rowe Jr. wrote:

On Thu, 11 Apr 2013 01:55:57 +0200
Guenter Knauf fua...@apache.org wrote:


I've now tested on Windows, and I can see all previously mentioned
issues there too; in addition the attached script which works fine on
NetWare crashes the Windows httpd ...


Backtrace, please?

I did test with a build from Gregg;
I'm in process of rebuilding my dev box, and its not yet ready to do 
so ...



A strange idea, but did you happen to build lua libs with the
identical Visual Studio version and mode as httpd (both debug,
or both release builds?)

I'm sure he did.


Yes, I know this and yes, both release and both vc9.


If you are mixing two different msvcrt flavors (debug/release,
or studio10/studio12) and the lua lib is performing any sort of
alloc/free of the resources allocated by httpd, this would be
a typical symptom.

I know; but I dont know if Gregg did a release or debug build;
I've heard a couple of times in the past that folks were not able to 
re-create crash with debug builds but which happen with release builds;
that could f.e. explain why Daniel doesnt see the issue with his debug 
build.



This is possible, I haven't tried debug build myself.

Gregg




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread Guenter Knauf

On 11.04.2013 12:25, Guenter Knauf wrote:

well, another possible fix would be this one:

Index: modules/lua/lua_request.c
===
--- modules/lua/lua_request.c(revision 1466743)
+++ modules/lua/lua_request.c(working copy)
@@ -1204,19 +1204,19 @@
  luaL_checktype(L, 2, LUA_TSTRING);
  r = ap_lua_check_request_rec(L, 1);
  filename = lua_tostring(L, 2);
-if (apr_stat(file_info, filename, APR_FINFO_NORM, r-pool) == OK) {
+if (apr_stat(file_info, filename, APR_FINFO_MIN, r-pool) == OK) {
  lua_newtable(L);

  lua_pushstring(L, mtime);
-lua_pushinteger(L, (ptrdiff_t)(file_info.mtime / 100));
+lua_pushnumber(L, file_info.mtime);
  lua_settable(L, -3);

  lua_pushstring(L, atime);
-lua_pushinteger(L, (ptrdiff_t)(file_info.atime / 100));
+lua_pushnumber(L, file_info.atime);
  lua_settable(L, -3);

  lua_pushstring(L, ctime);
-lua_pushinteger(L, (ptrdiff_t)(file_info.ctime / 100));
+lua_pushnumber(L, file_info.ctime);
  lua_settable(L, -3);

  lua_pushstring(L, size);

this way we bring the higher resolution of the time values into Lua;
however I've not yet checked if there are platforms which really provide
mtime/atime/ctime with a better resolution than 1 second;
if there are then it makes probably sense for the above patch, and then
do the divide if needed within the Lua scripts like:

local mtime = os.date(fmt, math.floor(info.mtime / 100))
r:puts( (%s was last modified at: %s\n):format(r.filename, mtime) )

since there might be usage cases for the time values other than feeding
os.date() for displaying, f.e. a simple compare; and one second is long ;-)

comments welcome!

no comment so far; I searched a bit more about this, and found:
http://en.wikipedia.org/wiki/Stat_%28system_call%29#Granularity_of_mtime.2C_etc.

therefore I will apply above patch to get the finer granularity into 
mod_lua.


Gün.





Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread Gregg Smith

On 4/12/2013 10:43 AM, Guenter Knauf wrote:

I know; but I dont know if Gregg did a release or debug build;
I've heard a couple of times in the past that folks were not able to 
re-create crash with debug builds but which happen with release builds;
that could f.e. explain why Daniel doesnt see the issue with his debug 
build.


This seems to be the case.
The attached lua script crashes on a Release build, but succeeds on a 
Debug build.


Regards,

Gregg

--[[
 This is the default method name for Lua handlers, see the optional
 function-name in the LuaMapHandler directive to choose a different
 entry point.
--]]

local iter = {  allowoverrides, ap_auth_type, ap_auth_type, args,
assbackwards, auth_name, banner, basic_auth_pw,
canonical_filename, content_encoding, content_type,
context_prefix, context_document_root, document_root,
err_headers_out, filename, handler, headers_in,
headers_out, hostname, is_https, is_initial_req,
limit_req_body, log_id, method, notes, options,
path_info, port, protocol, proxyreq, range,
remaining, server_built, server_name,
some_auth_required, subprocess_env, started, status,
the_request, unparsed_uri, uri, user, useragent_ip
 }

function iterator (obj)
  local i=1
  return function ()
local key = iter[i]
if key == nil then return end
i = i + 1
return key,obj[key]
  end
end

function handle(r)
  r.content_type = text/plain

  for key,val in iterator(r) do
r:puts( (%s=%q\n):format(key, tostring(val)) ) 
  end
  r:puts( (\nPowered by %s on %s\n):format(_VERSION, r:banner()) )
end


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-12 Thread Guenter Knauf

On 10.04.2013 23:21, Guenter Knauf wrote:

On 10.04.2013 23:01, fua...@apache.org wrote:

Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149

URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...



ok, onward with some more testing .

now on r:regex() ...

1) the sample in the docs is completely wrong ...
1.1) the docu has r:regex(string, pattern) but current code implements 
r:regex(pattern, string); I will change this in the code soon since I it 
looks more Lua-like for me what is in the docs since all other Lua match 
functions also have parameters in the order (string, pattern)
1.2) the pattern foo (%w+) (%S*) doesnt work for me; it looks more 
like a pattern for string.match(); instead a valid pattern for r:regex() 
would be f.e. foo (\\w+) (\\a+); backslash must be escaped in a Lua string


2) r:regex() crashes the server if more than AP_MAX_REG_MATCH matches 
are found; this is because we still get the real number of matches in 
regex.re_nsub although passing in AP_MAX_REG_MATCH:

rv = ap_regexec(regex, source, AP_MAX_REG_MATCH, matches, 0);

when I add:

if (regex.re_nsub  AP_MAX_REG_MATCH) {
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
  regex returned %d matches; allowed %d.,
  regex.re_nsub, AP_MAX_REG_MATCH);
return 2;
}

and test with a 20 match regex, I get this in the log:
regex returned 20 matches; allowed 10.

The docu of regexec() gives no hints about how to retrieve the real 
number of matches stored:

http://ci.apache.org/projects/httpd/trunk/doxygen/ap__regex_8h.html
and I've not yet digged into the code; but we need to make sure that the 
following loop doesnt loop over AP_MAX_REG_MATCH:

for (i = 0; i = regex.re_nsub; i++) {

BTW. what is the reason for limiting AP_MAX_REG_MATCH to 10 in httpd.h ?

Gün.




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Daniel Gruno
On 04/10/2013 11:21 PM, Guenter Knauf wrote:
 On 10.04.2013 23:01, fua...@apache.org wrote:
 Author: fuankg
 Date: Wed Apr 10 21:01:51 2013
 New Revision: 149

 URL: http://svn.apache.org/r149
 Log:
 Put this backport for now on hold to get some more
 time for testing ...
 
 ok, sorry for this - I'm all for the backport, but since I found few
 issues I would like to get some more testing done, and if these issues
 remain then we should solve them before the backport is done, or
 otherwise we end up again with a couple of backport fixes ...
 
 some things though I can already now mention ...
 based on the current docu:
 http://httpd.apache.org/docs/trunk/mod/mod_lua.html
 
 I tried some testing, and - being a Lua newbie I might get things wrong,
 but here's what I found so far:
 - banner(), port() and started() are functions (or methods), and listed
 as such below 'Built in functions'; but they are also listed as members
 of request_rec (see the big table); in addition started() gives
 certainly not seconds back but microseconds
 
 - add_version_component() doest work for me (on NetWare) but gives:
 Error: attempt to call method 'add_version_component' (a nil value)
 
 - the sample docu for r:stat() is wrong: info.modified - info.mtime
 
 - I get strange time values back from r:stat() on NetWare
 
 - r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me
 
 and while on env vars: any way to list all usual CGI env vars?
 ok, half of them can be obtained from the request_rec, but what about
 others which are inherited from the OS? Does os.getenv() work here?
 
 just wanted to mention what I found so far so that others can  test
 exactly these things, and either confirm or tell a 'works for me' ...
 
 ok, onward with some more testing .
 
 Gün.
 
 
 
Thanks for looking into this. I will fix up the documentation so it's
accurate, and look into fixing the other things.

As for the env variables, I had at one point thought about making a
binding for that, but possibly the already existing env table and
os.getenv will be enough - I'll investigate that.

Thanks for fixing the stat function

add_version_component does indeed seem to be missing - unsure whether we
really need it or not, so I'll just comment it out in the docs for now.

And yes, if we find some bugs, we should defo fix them before
backporting it all ;)

With regards,
Daniel


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Daniel Gruno
On 04/10/2013 11:21 PM, Guenter Knauf wrote:

 
 - r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me

This function does work perfectly, on Linux/FreeBSD at least ;)
it uses ap_expr, so whatever that function supports, this should as
well. What I tried on www.humbedooh.com was:

local match = r:expr(%{HTTP_HOST} =~ /^www/)
if match then
r:puts(expr matches)
else
r:puts(expr doesn't match)
end

and I got expr matches :)

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Guenter Knauf

Daniel,
On 11.04.2013 12:05, Daniel Gruno wrote:

Thanks for fixing the stat function

well, another possible fix would be this one:

Index: modules/lua/lua_request.c
===
--- modules/lua/lua_request.c   (revision 1466743)
+++ modules/lua/lua_request.c   (working copy)
@@ -1204,19 +1204,19 @@
 luaL_checktype(L, 2, LUA_TSTRING);
 r = ap_lua_check_request_rec(L, 1);
 filename = lua_tostring(L, 2);
-if (apr_stat(file_info, filename, APR_FINFO_NORM, r-pool) == OK) {
+if (apr_stat(file_info, filename, APR_FINFO_MIN, r-pool) == OK) {
 lua_newtable(L);

 lua_pushstring(L, mtime);
-lua_pushinteger(L, (ptrdiff_t)(file_info.mtime / 100));
+lua_pushnumber(L, file_info.mtime);
 lua_settable(L, -3);

 lua_pushstring(L, atime);
-lua_pushinteger(L, (ptrdiff_t)(file_info.atime / 100));
+lua_pushnumber(L, file_info.atime);
 lua_settable(L, -3);

 lua_pushstring(L, ctime);
-lua_pushinteger(L, (ptrdiff_t)(file_info.ctime / 100));
+lua_pushnumber(L, file_info.ctime);
 lua_settable(L, -3);

 lua_pushstring(L, size);

this way we bring the higher resolution of the time values into Lua;
however I've not yet checked if there are platforms which really provide 
mtime/atime/ctime with a better resolution than 1 second;
if there are then it makes probably sense for the above patch, and then 
do the divide if needed within the Lua scripts like:


local mtime = os.date(fmt, math.floor(info.mtime / 100))
r:puts( (%s was last modified at: %s\n):format(r.filename, mtime) )

since there might be usage cases for the time values other than feeding 
os.date() for displaying, f.e. a simple compare; and one second is long ;-)


comments welcome!


add_version_component does indeed seem to be missing - unsure whether we
really need it or not, so I'll just comment it out in the docs for now.

not sure either - but it was there, so I did test it.

Gün.




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Guenter Knauf

On 11.04.2013 12:10, Daniel Gruno wrote:

On 04/10/2013 11:21 PM, Guenter Knauf wrote:



- r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me


This function does work perfectly, on Linux/FreeBSD at least ;)
it uses ap_expr, so whatever that function supports, this should as
well. What I tried on www.humbedooh.com was:

 local match = r:expr(%{HTTP_HOST} =~ /^www/)
 if match then
 r:puts(expr matches)
 else
 r:puts(expr doesn't match)
 end

and I got expr matches :)
ok, I admit that I didnt test exactly this sample; but the usage of 
%{HTTP_HOST} there made me think that it will always be expanded, f.e. like:

r:puts(HTTP_HOST=%{HTTP_HOST}\n)
and this didnt work ...

Gün.





Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Guenter Knauf

On 11.04.2013 12:05, Daniel Gruno wrote:

As for the env variables, I had at one point thought about making a
binding for that, but possibly the already existing env table and
os.getenv will be enough - I'll investigate that.
as I said I'm a Lua newbie - can you perhaps give me an example how I 
can display the values of r:subprocess_env - preferredly an iterate over 
this table?


thanks, Gün.






Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Daniel Gruno
On 04/11/2013 12:33 PM, Guenter Knauf wrote:
 On 11.04.2013 12:05, Daniel Gruno wrote:
 As for the env variables, I had at one point thought about making a
 binding for that, but possibly the already existing env table and
 os.getenv will be enough - I'll investigate that.
 as I said I'm a Lua newbie - can you perhaps give me an example how I
 can display the values of r:subprocess_env - preferredly an iterate over
 this table?
 
 thanks, Gün.
 
 
 
 
it's a userdata object, so you can't iterate over the key/value pairs,
you can only access the values directly if you know the key.

r.subprocess_env['foo'] will return something if the 'foo' value is set
in httpd.

We could change this I suppose, if an iteration is needed in a specific
use case.

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Guenter Knauf

On 11.04.2013 12:44, Daniel Gruno wrote:

it's a userdata object, so you can't iterate over the key/value pairs,
you can only access the values directly if you know the key.
I was hoping that its possible to create a table from the userdata with 
some Lua magic, and then iterate over the table ...


oh, and some more questions:
whats the benefit of having banner(), port() and started() as functions 
(or methods)?

isnt it fine accessing these like f.e. r.filename?
r:put(r.banner) would be even shorter than r:put(r:banner()) ...

and why is it:
r.module_info(module_name)
and not:
r:module_info(module_name)

??




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Daniel Gruno
On 04/11/2013 02:36 PM, Guenter Knauf wrote:
 On 11.04.2013 12:44, Daniel Gruno wrote:
 it's a userdata object, so you can't iterate over the key/value pairs,
 you can only access the values directly if you know the key.
 I was hoping that its possible to create a table from the userdata with
 some Lua magic, and then iterate over the table ...
 
 oh, and some more questions:
 whats the benefit of having banner(), port() and started() as functions
 (or methods)?
 isnt it fine accessing these like f.e. r.filename?
 r:put(r.banner) would be even shorter than r:put(r:banner()) ...
 
 and why is it:
 r.module_info(module_name)
 and not:
 r:module_info(module_name)
 
 ??
 
 
I'll look into adding them as variables instead :)

r.module_info is because it doesn't need the request_rec object to get
module information (foo:bar(baz) is short for foo.bar(foo, baz) ).

I admit, it can be a bit confusing, and perhaps we should consider
turning it into r:module_info for the sake of conformity, but I don't
consider it a bug or anything that would stall a backport.

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Daniel Gruno
On 04/11/2013 01:55 AM, Guenter Knauf wrote:
 On 10.04.2013 23:34, Guenter Knauf wrote:
 but here's what I found so far:
 - banner(), port() and started() are functions (or methods), and listed
 as such below 'Built in functions'; but they are also listed as members
 of request_rec (see the big table); in addition started() gives
 certainly not seconds back but microseconds

 - add_version_component() doest work for me (on NetWare) but gives:
 Error: attempt to call method 'add_version_component' (a nil value)

 - the sample docu for r:stat() is wrong: info.modified - info.mtime

 - I get strange time values back from r:stat() on NetWare

 - r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me

 one more issue I saw:
 - r.module_info() returns directives where the closing tag is missing,
 f.e.:
 Directory
 instead of:
 Directory
 I've now tested on Windows, and I can see all previously mentioned
 issues there too; in addition the attached script which works fine on
 NetWare crashes the Windows httpd ...
 
 Gregg, do you see same, and if so can you perhaps capture debug info and
 post here?
 
 Gün.
 
I just tried the script you attached on my Windows box, as well as the
original LuaRoot + LuaMapHandler problem, and I can't find anything
wrong with it, it works flawlessly with httpd 2.4.4 + mod_lua from trunk
(using Lua 5.1.4). There appears to be nothing in the code that triggers
it (go look yourself, I can't find anything), so I'm just about to chalk
it up to Windows (or possibly Lua for Windows) just acting weird for
some people.

So, to sum up; I can't reproduce either of the crashes on my Windows 7
machine :(

With regards,
Daniel.


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Gregg Smith

On 4/11/2013 9:05 AM, Daniel Gruno wrote:

I just tried the script you attached on my Windows box, as well as the
original LuaRoot + LuaMapHandler problem, and I can't find anything
wrong with it, it works flawlessly with httpd 2.4.4 + mod_lua from trunk
(using Lua 5.1.4). There appears to be nothing in the code that triggers
it (go look yourself, I can't find anything), so I'm just about to chalk
it up to Windows (or possibly Lua for Windows) just acting weird for
some people.

So, to sum up; I can't reproduce either of the crashes on my Windows 7
machine :(


Ok, so it's not Lua 5.1.5 or 5.2.2 as I just tried with 5.1.4 and 
trunk's mod_lua of r1466822

I've ruled out the UAC in Vista, run from console vs. Windows Service.

So I'm curious, what did you build with (vc10/mingw/etc)?

Regards,

Gregg


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-11 Thread Guenter Knauf

Hi Daniel,
On 11.04.2013 18:05, Daniel Gruno wrote:

I just tried the script you attached on my Windows box, as well as the
original LuaRoot + LuaMapHandler problem, and I can't find anything
wrong with it, it works flawlessly with httpd 2.4.4 + mod_lua from trunk
(using Lua 5.1.4). There appears to be nothing in the code that triggers
it (go look yourself, I can't find anything), so I'm just about to chalk
it up to Windows (or possibly Lua for Windows) just acting weird for
some people.

So, to sum up; I can't reproduce either of the crashes on my Windows 7
machine :(
ok, just to rule build issues out too - can you perhaps pack and your 
binaries and put them into your home dir so that we can test with these?


BTW. we both see similar crashes with your mod_plua on Windows too (it 
runs fine on some boxes here, f.e. httpd 2.2.22 x86 on XP, 2.4.4 on XP 
and W7, but both not on W2K3); so ideally would be if you could build 
and add that too ...


thanks,  Gün.




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-10 Thread Guenter Knauf

On 10.04.2013 23:01, fua...@apache.org wrote:

Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149

URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...


ok, sorry for this - I'm all for the backport, but since I found few 
issues I would like to get some more testing done, and if these issues 
remain then we should solve them before the backport is done, or 
otherwise we end up again with a couple of backport fixes ...


some things though I can already now mention ...
based on the current docu:
http://httpd.apache.org/docs/trunk/mod/mod_lua.html

I tried some testing, and - being a Lua newbie I might get things wrong, 
but here's what I found so far:
- banner(), port() and started() are functions (or methods), and listed 
as such below 'Built in functions'; but they are also listed as members 
of request_rec (see the big table); in addition started() gives 
certainly not seconds back but microseconds


- add_version_component() doest work for me (on NetWare) but gives:
Error: attempt to call method 'add_version_component' (a nil value)

- the sample docu for r:stat() is wrong: info.modified - info.mtime

- I get strange time values back from r:stat() on NetWare

- r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me

and while on env vars: any way to list all usual CGI env vars?
ok, half of them can be obtained from the request_rec, but what about 
others which are inherited from the OS? Does os.getenv() work here?


just wanted to mention what I found so far so that others can  test 
exactly these things, and either confirm or tell a 'works for me' ...


ok, onward with some more testing .

Gün.





Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-10 Thread Guenter Knauf

On 10.04.2013 23:21, Guenter Knauf wrote:

On 10.04.2013 23:01, fua...@apache.org wrote:

Author: fuankg
Date: Wed Apr 10 21:01:51 2013
New Revision: 149

URL: http://svn.apache.org/r149
Log:
Put this backport for now on hold to get some more
time for testing ...


ok, sorry for this - I'm all for the backport, but since I found few
issues I would like to get some more testing done, and if these issues
remain then we should solve them before the backport is done, or
otherwise we end up again with a couple of backport fixes ...

some things though I can already now mention ...
based on the current docu:
http://httpd.apache.org/docs/trunk/mod/mod_lua.html

I tried some testing, and - being a Lua newbie I might get things wrong,
but here's what I found so far:
- banner(), port() and started() are functions (or methods), and listed
as such below 'Built in functions'; but they are also listed as members
of request_rec (see the big table); in addition started() gives
certainly not seconds back but microseconds

- add_version_component() doest work for me (on NetWare) but gives:
Error: attempt to call method 'add_version_component' (a nil value)

- the sample docu for r:stat() is wrong: info.modified - info.mtime

- I get strange time values back from r:stat() on NetWare

- r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me


one more issue I saw:
- r.module_info() returns directives where the closing tag is missing, f.e.:
Directory
instead of:
Directory

Gün.




Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-10 Thread Guenter Knauf

On 10.04.2013 23:34, Guenter Knauf wrote:

but here's what I found so far:
- banner(), port() and started() are functions (or methods), and listed
as such below 'Built in functions'; but they are also listed as members
of request_rec (see the big table); in addition started() gives
certainly not seconds back but microseconds

- add_version_component() doest work for me (on NetWare) but gives:
Error: attempt to call method 'add_version_component' (a nil value)

- the sample docu for r:stat() is wrong: info.modified - info.mtime

- I get strange time values back from r:stat() on NetWare

- r:expr(string) sample uses %{HTTP_HOST}, but that doesnt work for me


one more issue I saw:
- r.module_info() returns directives where the closing tag is missing,
f.e.:
Directory
instead of:
Directory
I've now tested on Windows, and I can see all previously mentioned 
issues there too; in addition the attached script which works fine on 
NetWare crashes the Windows httpd ...


Gregg, do you see same, and if so can you perhaps capture debug info and 
post here?


Gün.

--[[
 This is the default method name for Lua handlers, see the optional
 function-name in the LuaMapHandler directive to choose a different
 entry point.
--]]

local iter = {  allowoverrides, ap_auth_type, ap_auth_type, args,
assbackwards, auth_name, banner, basic_auth_pw,
canonical_filename, content_encoding, content_type,
context_prefix, context_document_root, document_root,
err_headers_out, filename, handler, headers_in,
headers_out, hostname, is_https, is_initial_req,
limit_req_body, log_id, method, notes, options,
path_info, port, protocol, proxyreq, range,
remaining, server_built, server_name,
some_auth_required, subprocess_env, started, status,
the_request, unparsed_uri, uri, user, useragent_ip
 }

function iterator (obj)
  local i=1
  return function ()
local key = iter[i]
if key == nil then return end
i = i + 1
return key,obj[key]
  end
end

function handle(r)
  r.content_type = text/plain

  for key,val in iterator(r) do
r:puts( string.format(%s=%q\n, key, tostring(val)) ) 
  end
  r:puts( string.format(\nPowered by %s on %s\n, _VERSION, r:banner()) )
end


Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS

2013-04-10 Thread Guenter Knauf

On 10.04.2013 23:34, Guenter Knauf wrote:

one more issue I saw:
- r.module_info() returns directives where the closing tag is missing,
f.e.:
Directory
instead of:
Directory
ok, this one sorted out - looked at the code, and its because the 
directives available from command_rec come without closing tag; I was 
expecting same output as mod_info shows, but now clear why it differs ...

so not a bug ...

Gün.