Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
