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

[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: use connection hostname for SNI and SSLProxyCheckPeerCN instead of the Host: header

[Lam, Eugene]

Hi Kaspar,

Thanks for digging up that thread.  I still think SNI needs to be considered, 
but not in the way I originally thought!

On 4/10/13 9:43 PM, "Kaspar Brand" 
mailto:httpd-dev.2...@velox.ch>> wrote:
On 10.04.2013 02:49, Lam, Eugene wrote:
ssl_engine_io.c will pull out this note and use it for SNI and
SSLProxyCheckPeerCN.  Unfortunately, www.example.com does not match
backend.example.com.

I wouldn't call this unfortunate, I would say that it's a
misunderstanding of what SSL proxying with mod_proxy_http is expected to
provide.

To help "iron out" any misunderstanding, I'll repeat what I know.  There's at 
least 2 types of ways to configure mod_proxy_http.  I'm only interested in the 
ProxyPassReverse, not ProxyPass.

In the classic *reverse proxy* setup, the CN is always different between 1) the 
cert on the reverse proxy that terminated the original HTTP request and 2) the 
cert on the backend server terminating the backend HTTP request.  In other 
words, the reverse proxy (responding to request for www.example.com) has 
already terminated the secure connection with the original HTTP requester.  The 
reverse proxy is initiating a new connection with "backend.example.com", 
assuming "backend.example.com" is what appeared in the ProxyPassReverse 
directive.  This is expected, right?

When ProxyPreserveHost is off, everything works fine.  The backend HTTP 
request's Host header would be backend.example.com, and mod_ssl sees a cert 
with CN=backend.example.com.  This is the expected behavior and is the 
supported configuration.

Turning on ProxyPreserveHost breaks this by affecting the Host header.  It 
changes the backend HTTP request from the ProxyPassReverse value into the value 
of Host header the original HTTP requester.

The reverse proxy shouldn't expect CN=www.example.com,
CN=www.example.org, etc. when the backend only has
CN=backend.example.com.

Looks like you're trying to use a "generic" SSL tunnel for any HTTP
request, irrespective of the host name in its URL. This is prone to MitM
attacks, and hardly a good idea. See also this message:

http://mail-archives.apache.org/mod_mbox/httpd-dev/201204.mbox/%3C4F8E7873.804%40velox.ch%3E


In my case, the intent of `ProxyPreserveHost on` is to trick the applications 
at backend.example.com into thinking it's directly getting the request bound 
for www.example.com.  The correct way would have been to rewrite applications 
to recover the info from X-Forwarded-Host, I don't deny that.  My guess is, the 
history/motivation of the ProxyPreserveHost directive is for compatibility with 
older, fossilized applications that can only understand Host header and not 
X-Forwarded-Host.  It also helps with a reverse proxy that has to talk to both 
old and new applications at the same time.

What I take away from reading "SNI with apache 2.4.1 reverse proxy" thread is: 
use ProxyPreserveHost at your own risk, it doesn't work quite right for reverse 
proxy, although it doesn't stop some users from trying.  It seems to me the 
Host header is an unstable source for SSLProxyCheckPeerCN when 
`ProxyPreserveHost on`.  Is this conclusion logical?

So, I am suggesting a patch for mod_ssl to use the "connection-level" hostname 
from ProxyPassReverse for SSLProxyCheckPeerCN.  I think it only *appears* to be 
like MitM, because the backend is returning a cert with different CN than the 
backend request's Host header.  It is still the job of the proxy server to 
decide what is expected, right?  In ProxyPreserveHost off case, it was 
expecting backend.example.com.  When ProxyPreserveHost is on, it got 
backend.example.com still; it shouldn't be any more at risk for MitM.  But, the 
backend is in a sense ignoring the SNI.  You are right in that SNI isn't my 
goal here, the goal is making SSLProxyCheckPeerCN a bit more sensible without 
turning it off completely.

Peter Sylvester 
mentioned that "If something is put into the SNI, it must be identical to what 
is in the Host:header."  Perhaps I should leave SNI values alone, but instead 
introduce a directive called SSLProxyExpectPeerCNSupportsSNI.  If off, then 
still proceed if the backend don’t obey SNI but ends up returning a cert with 
CN equal to the connection-level hostname.  This way, SNI will still be 
attempted.  Thoughts?

Eugene Lam

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

[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

[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: 2.4.4 graceful restart taking long time

[Arkadiusz Miśkiewicz]

On Thursday 11 of April 2013, Arkadiusz Miśkiewicz wrote:

> Another strace including children
> http://ixion.pld-linux.org/~arekm/apache1.txt
> 
> Graceful restart and first OPTIONS write at
> 
> 12594 15:10:01.397356 write(7, "OPTIONS * HTTP/1.0\r\nUser-Agent:
> Apache/2.4.4 (Unix) (internal dummy connection)\r\n\r\n", 83  ...>

Another observation.

When this happens (when dummy_connection() is called, my " XXX dummy 2 
processing X" are printed) then in that time all children are already 
zombie/defunct, so they cannot answer/do anything. The only living process is 
master process.

> 
> but first read is long after write
> 
> 13279 15:10:52.636685 <... read resumed> "OPTIONS * HTTP/1.0\r\nUser-Agent:
> Apache/2.4.4 (Unix) (internal dummy connection)\r\n\r\n", 8000) = 83
> <0.14>

And that's read by new generation I think

Old generation childs exit in:

else if (retained->my_generation !=
 ap_scoreboard_image->global->running_generation) { /* 
restart? */
/* yeah, this could be non-graceful restart, in which case the
 * parent will kill us soon enough, but why bother checking?
 */
die_now = 1;
}

So looks like master process is trying to send data (in dummy_connection()) to 
childrens that already exit()ed leading to whole slowdown. This is how it 
looks http://ixion.pld-linux.org/~arekm/apache3.txt

Opinions?


13:38:03.383798 connect(7, {sa_family=AF_INET, sin_port=htons(80), 
sin_addr=inet_addr("192.168.1.121")}, 16) = -1 EINPROGRESS (Operation now in 
progress) <0.24>
13:38:03.383841 poll([{fd=7, events=POLLOUT}], 1, 3000) = 1 ([{fd=7, 
revents=POLLOUT}]) <0.06>
13:38:03.383872 getsockopt(7, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 <0.06>
13:38:03.383897 write(7, "OPTIONS * HTTP/1.0\r\nUser-Agent: Apache/2.4.4 
(Unix) (internal dummy connection)\r\n\r\n", 83) = 83 <0.22>

4 in SO_ERROR is a "Interrupted system call", so could support my suspicion

> 
> Huh?
> 
> That's even after resuming operations mesage which was a bit earlier:
> 
> 12594 15:10:52.606253 write(2, "[Thu Apr 11 15:10:52.606236 2013]
> [mpm_prefork:notice] [pid 12594] AH00163: Apache/2.4.4 (Unix) configured --
> resuming normal operations\n", 137) = 137 <0.09>
> 
> Compare that to case where ab wasn't running:
> http://ixion.pld-linux.org/~arekm/apache-no-ab.txt
> write OPTIONS in main process and read in childrens are interleaving as
> expected.
> 
> Now why these aren't interleaving in apache1.txt where ab was running?
> 
> > As the accept call
> > on httpd side only returns when the first data is send on the socket,
> > IMHO the time the poll takes does take place in the kernel and not in
> > the httpd children code.
> 
> Well, I think kernel is not the one to blame.
> 
> > Have you checked your messages file if the kernel reports
> > something when this happens? How does your run queue and CPU load look
> > like when this happens (top)?
> 
> No kernel messages, no cpu spikes - looks normal.
> 
> > Regards
> > Rüdiger


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl

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

[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.:
>> > instead of:
>> 
> 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: 2.4.4 graceful restart taking long time

[Arkadiusz Miśkiewicz]

On Thursday 11 of April 2013, Plüm, Rüdiger, Vodafone Group wrote:

> > On apache 2.2.22, 2.2.23 and 2.4.4 I'm able to reproduce a problem
> > where graceful restart takes very long time. Linux 3.7.10, glibc 2.17
> > here.
> > Example strace of main httpd process while doing graceful restart:
> > http://pastebin.com/QFH5TjT6
> 
> From the strace

Here is similar strace but without ab running, one second is enough
http://pastebin.com/HKjxxP2p (StartServers 64 this time, ab -c 64)

> it looks like the connect takes a lot of time later on (the
> poll is waiting 1 second for the connect to complete). 

That strace was done with StartServers 128 but ab was using -c 64, so looks 
like idle children responded fast (that first second), busy - too slowly.

Another strace including children
http://ixion.pld-linux.org/~arekm/apache1.txt

Graceful restart and first OPTIONS write at 

12594 15:10:01.397356 write(7, "OPTIONS * HTTP/1.0\r\nUser-Agent: Apache/2.4.4 
(Unix) (internal dummy connection)\r\n\r\n", 83 

but first read is long after write

13279 15:10:52.636685 <... read resumed> "OPTIONS * HTTP/1.0\r\nUser-Agent: 
Apache/2.4.4 (Unix) (internal dummy connection)\r\n\r\n", 8000) = 83 
<0.14>

Huh?

That's even after resuming operations mesage which was a bit earlier:

12594 15:10:52.606253 write(2, "[Thu Apr 11 15:10:52.606236 2013] 
[mpm_prefork:notice] [pid 12594] AH00163: Apache/2.4.4 (Unix) configured -- 
resuming normal operations\n", 137) = 137 <0.09>

Compare that to case where ab wasn't running:
http://ixion.pld-linux.org/~arekm/apache-no-ab.txt
write OPTIONS in main process and read in childrens are interleaving as 
expected.

Now why these aren't interleaving in apache1.txt where ab was running?

> As the accept call
> on httpd side only returns when the first data is send on the socket, IMHO
> the time the poll takes does take place in the kernel and not in the httpd
> children code.

Well, I think kernel is not the one to blame.

> Have you checked your messages file if the kernel reports
> something when this happens? How does your run queue and CPU load look
> like when this happens (top)?

No kernel messages, no cpu spikes - looks normal.

> Regards
> Rüdiger

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl

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

[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

[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: 2.4.4 graceful restart taking long time

[Plüm , Rüdiger , Vodafone Group]

> -Original Message-
> From: Arkadiusz Miśkiewicz [mailto:ar...@maven.pl]
> Sent: Donnerstag, 11. April 2013 13:43
> To: dev@httpd.apache.org
> Subject: 2.4.4 graceful restart taking long time
> 
> 
> Hello,
> 
> On apache 2.2.22, 2.2.23 and 2.4.4 I'm able to reproduce a problem
> where graceful restart takes very long time. Linux 3.7.10, glibc 2.17
> here.
> Example strace of main httpd process while doing graceful restart:
> http://pastebin.com/QFH5TjT6

From the strace it looks like the connect takes a lot of time later on (the 
poll is waiting 1 second for
the connect to complete). As the accept call on httpd side only returns when 
the first data is send on the socket,
IMHO the time the poll takes does take place in the kernel and not in the httpd 
children code.
Have you checked your messages file if the kernel reports something when this 
happens?
How does your run queue and CPU load look like when this happens (top)?

Regards

Rüdiger

2.4.4 graceful restart taking long time

[Arkadiusz Miśkiewicz]

Hello,

On apache 2.2.22, 2.2.23 and 2.4.4 I'm able to reproduce a problem
where graceful restart takes very long time. Linux 3.7.10, glibc 2.17 here.

keepalive is off, ServerLimit  600; StartServers  64; MinSpareServers 32;
MaxSpareServers 64; MaxClients 600; MaxRequestsPerChild  2000;
minimal number of apache modules

I'm running ab where 192.168.1.121 is my local ip:
/usr/bin/ab -n 10 -c 64 http://192.168.1.121/
(ususally I'm interrupting ab in first 1-2 seconds of its run, starting it 
again and leaving running)

and then doing graceful restart while ab is still running:
[Thu Apr 11 13:27:32.624875 2013] [mpm_prefork:notice] [pid 10202] AH00171: 
Graceful restart requested, doing restart
[Thu Apr 11 13:28:15.836068 2013] [mpm_prefork:notice] [pid 10202] AH00163: 
Apache/2.4.4 (Unix) configured -- resuming normal operations

It takes almost 1 minute to resume operations. Now if I don't do
ab "magic" then resume is immediate (1-2s).

The whole time is spend in prefork ap_mpm_pod_killpg

ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf, APLOGNO(00171)
"Graceful restart requested, doing restart");

/* kill off the idle ones */
ap_mpm_pod_killpg(pod, retained->max_daemons_limit);

where ap_mpm_pod_killpg iterates over childrens (?) and that takes ~1 minute.

I also did testing with StartServers 128. ap_mpm_pod_killpg had to iterate
over 128 childrens where 72 of them were done in the same second while
the rest in over minute - log here http://pastebin.com/3tP5hW1f.

Example strace of main httpd process while doing graceful restart:
http://pastebin.com/QFH5TjT6

The whole problem is that until ap_mpm_pod_killpg finishes apache
is not responding to new requests and the downtime is between 30s
to even 4 minutes.

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl

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

[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

[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

[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

[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

[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

[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