Re: Style
Hi Christophe, On 06.10.2014 22:08, Christophe JAILLET wrote: So, do you think that such clean up worth the effort or that things should be left as-is ? Thanks for feed back. just a note about style: while it doesnt matter if styles are fixed in C files, it *does* matter if you try to fix them in headers: there are 3 awk scripts in ./build which try to catch function names from headers in order to generate export lists; if you fix some prototypes in headers which have lines longer than 80 chars then these scripts get broken, and its probably not trivial to fix those scripts to get them working again ... (f.e. we use make_nw_export.awk for the NetWare build) Gün.
Re: C99 bump prior to apr 2.0?
Hi Bill, On 03.09.2014 18:27, wr...@rowe-clan.net wrote: In terms of providing dist/httpd/binaries/win32 httpd 2.2.29 based on msvcrt,dll, I have a couple of options; [x] Ship with r1563992 applied (and document this? where?) [ ] Drop apr_dbd_odbc.dll from the distribution [ ] Don't ship as Gregg suggested just document in the README ... Any preferences? If option 1 is elected, the second question is whether to update the -win32-src.zip distro as an -r2? This will only affect the VC6/Studio 97 builds, since the more recent visual studio releases have some level of C99 support. either that, or probably put the patch into apply-to folder; I have no preference ... Gün.
Re: http/2 Apache module
On 27.08.2014 16:13, Eric Covener wrote: On Wed, Aug 27, 2014 at 9:47 AM, hugues.desa...@orange.com wrote: Thanks for your answer; I was also wondering if Apache was willing to use already existing http/2 stack implementations, like nghttp2 (https://nghttp2.org) ? Only speaking for myself as a committer, I think it's a reasonable thing to explore -- don't think it's a showstopper (MIT licensed, C and not C++) but it's something community would have to weigh when it was father along. nghttp2 got some polishment during last months when the author brought patches to libcurl: http://curl.haxx.se/dev/readme-http2.html I think it would probably be a good thing to depend on it - at least for a start ... Gün.
Re: svn commit: r1612653 - /httpd/httpd/trunk/server/util_pcre.c
Hi Rainer, On 23.07.2014 12:18, Rainer Jung wrote: Good point. But in this case even after dropping the check, it would mean the build would error out because PCRE_DUPNAMES isn't known. So then you would have to check the (new) info in the docs, that minimum PCRE version is 6.7. I meant to keep this check (which you removed with 1612921) ... Of course an #error message would help because it is more explicit, but I think that's not how the code currently is structured in general. If there is a dependency for a library version, we don't check in the sources whether the right version is available. not true - we do; f.e. from mod_ssl_ct.c: #include apr_version.h #if !APR_VERSION_AT_LEAST(1,5,0) #error mod_ssl_ct requires APR 1.5.0 or later! (for apr_escape.h) #endif and: #if OPENSSL_VERSION_NUMBER 0x10002001L #error mod_ssl_ct requires OpenSSL 1.0.2-beta1 or later #endif and I'm sure there are many more similar places ... but I think the check should directly happen after pcre.h is included and not in the middle of code; see 1612945. Günter.
Re: svn commit: r1612653 - /httpd/httpd/trunk/server/util_pcre.c
Hi Rainer, On 22.07.2014 23:01, Rainer Jung wrote: documenting the requirement PCRE = 6.7 and dropping the check (and error message) for PCRE_DUPNAMES from server/util_pcre.c. -1. Please think of non-configure builds; it doesnt hurt if the code errors out when the requirements do not met. Gün.
Re: [VOTE] Release Apache httpd 2.4.10 as GA
On 15.07.2014 19:20, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.10 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 with NetWare.
mod_autoindex issue with multibyte chars
Hi all, few days back I found that mod_autoindex seems to have a prob with multibyte chars in filenames; the trailing spaces seem to be calculated for the real string, but since they're finally displayed in the browser as one char this causes lack of spaces and the following data is misaligned ... I've seen this 1st with Windows and thought it might be because the filesystem uses another charset than httpd; but today I tested some more, and see same issue also on Linux: http://people.apache.org/~fuankg/testautoindex/ I've not yet looked through mod_autoindex due lack of time, but I thought just I mention it here in case someone finds quickly a fix; affected are 2.2.x and 2.4.x and most likely trunk too. Gün.
Re: [VOTE] Release Apache httpd 2.4.6 as GA
On 15.07.2013 18:48, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.6 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.6 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 on NetWare.
Re: [VOTE] Release Apache httpd 2.4.5 as GA
On 11.07.2013 20:54, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.5 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.5 GA. NOTE: The -deps tarballs are included here *only* to make life easier for the tester. They will not be, and are not, part of the official release. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 for NetWare. Gün.
re: svn commit: r1501848 - /httpd/httpd/branches/2.4.x/STATUS
Hi Jim,
Modified: httpd/httpd/branches/2.4.x/STATUS
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1501848r1=1501847r2=1501848view=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Wed Jul 10 16:53:22 2013
@@ -221,6 +221,10 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
http://svn.apache.org/r1500519
2.4.x patch: trunk patches work
+1: fuankg
+comments:
+ jj: In general, casts are sometimes used to hide problems
+ that exist, esp when using the incorrect data types...
+ Are these casts safe?
I think I did my best to not hide problems but instead tried to use the
right data types where ever possible ...
* fixed data type *
Index: modules/filters/mod_charset_lite.c
===
--- modules/filters/mod_charset_lite.c (revision 1500344)
+++ modules/filters/mod_charset_lite.c (revision 1500345)
@@ -474,7 +474,7 @@
charset_filter_ctx_t *ctx = f-ctx;
const char *msg;
char msgbuf[100];
-int len;
+apr_size_t len;
switch(ctx-ees) {
case EES_LIMIT:
* AFAIK lua has only 2 datatypes int and double, so this cast is required *
Index: modules/lua/lua_request.c
===
--- modules/lua/lua_request.c (revision 1500361)
+++ modules/lua/lua_request.c (revision 1500362)
@@ -884,7 +884,7 @@
r = ap_lua_check_request_rec(L, 1);
luaL_checktype(L, 2, LUA_TSTRING);
path = lua_tostring(L, 2);
-mtime = luaL_optnumber(L, 3, apr_time_now());
+mtime = (apr_time_t)luaL_optnumber(L, 3, (lua_Number)apr_time_now());
status = apr_file_mtime_set(path, mtime, r-pool);
lua_pushboolean(L, (status == 0));
return 1;
* fixed data type *
Index: modules/cache/mod_socache_memcache.c
===
--- modules/cache/mod_socache_memcache.c(revision 1500361)
+++ modules/cache/mod_socache_memcache.c(revision 1500362)
@@ -85,7 +85,7 @@
{
apr_status_t rv;
int thread_limit = 0;
-int nservers = 0;
+apr_uint16_t nservers = 0;
char *cache_config;
char *split;
char *tok;
* this cast is needed because the expression is int but the function sig
is char; as you can see 2 lines above ap_rputc() doesnt need this
because it takes an int argument and does then self cast ... *
Index: modules/generators/mod_info.c
===
--- modules/generators/mod_info.c (revision 1500361)
+++ modules/generators/mod_info.c (revision 1500362)
@@ -113,7 +113,7 @@
if (r)
ap_rputc('0' + i % 10, r);
else
-apr_file_putc('0' + i % 10, out);
+apr_file_putc((char)('0' + i % 10), out);
}
else {
if (r)
* fixed data type *
Index: modules/proxy/mod_proxy_connect.c
===
--- modules/proxy/mod_proxy_connect.c (revision 1500422)
+++ modules/proxy/mod_proxy_connect.c (revision 1500423)
@@ -220,7 +220,7 @@
apr_uri_t uri;
const char *connectname;
-int connectport = 0;
+apr_port_t connectport = 0;
/* is this for us? */
if (r-method_number != M_CONNECT) {
* fixed data type where possible; if the cast to bodylen is wrong then
the signature of fill_in_header() is wrong and should take apr_size_t
instead *
Index: modules/proxy/mod_proxy_fcgi.c
===
--- modules/proxy/mod_proxy_fcgi.c (revision 1500422)
+++ modules/proxy/mod_proxy_fcgi.c (revision 1500423)
@@ -234,7 +234,8 @@
return rv;
}
-static apr_status_t send_begin_request(proxy_conn_rec *conn, int
request_id)
+static apr_status_t send_begin_request(proxy_conn_rec *conn,
+ apr_uint16_t request_id)
{
struct iovec vec[2];
fcgi_header header;
@@ -266,7 +267,7 @@
}
static apr_status_t send_environment(proxy_conn_rec *conn, request_rec *r,
- int request_id)
+ apr_uint16_t request_id)
{
const apr_array_header_t *envarr;
const apr_table_entry_t *elts;
@@ -390,7 +391,7 @@
itr += vallen;
}
-fill_in_header(header, FCGI_PARAMS, request_id, bodylen, 0);
+fill_in_header(header, FCGI_PARAMS, request_id,
(apr_uint16_t)bodylen, 0);
fcgi_header_to_array(header, farray);
vec[0].iov_base = (void *)farray;
@@ -543,7 +544,7 @@
}
static apr_status_t dispatch(proxy_conn_rec *conn, proxy_dir_conf *conf,
- request_rec *r, int request_id)
+ request_rec *r, apr_uint16_t request_id)
{
apr_bucket_brigade *ib, *ob;
int
Re: [VOTE] The 'RM' Baton
On 10.07.2013 15:22, Jim Jagielski wrote: Considering that I've been the only RM for 2.4.x, I can't help but assume that Bill is referring to me. As mentioned by others, by indicating a desire to TR, it energizes people to catch up on STATUS, place their votes and propose backports. So it is *expected* that at a time when things should be the most stable (right before a release), that there is a flurry of activity. So what if it means a delay of a few weeks or even a month. The result is a *better* release for our users, which I think is even more important. well, but this concept is IMO not very efficient; often it happend that things were then backported in a rush to get things in with *this* pending release, and afterwards shows that it broke something on platforms which are not in the main focus (but that woudnt matter if we would release more often). Also it is not required for a new release to come with a ChangeLog of at least 10 entries - if we have only 5 then lets get the 5 to the users! I was also thinking about learning how to release - but the lack of proper documentation for the whole process holds me back; I remember how Graham fell from one trap into another when he did his 1st APR release, and I dont want to get same ... so, if we want to have more folks doing more frequently releases the startpoint would be to 1st document how a release is done: - required auto* tools versions - step by step description how to prepare for a release what would also help here is a way to do a test-release ... ;-) also I would be +++1 for making fix dates for releases, f.e. lets say 4 times a year which means all 3 months - and then doing the release *REGARDLESS* if we have thing hanging in STATUS or not! What doesnt go into this release does make it for the next, and that would then only be 3 months. But I would *NOT* vote for such unless I'm self able to do releases. As an example you may look at the libcurl project - we do there every ~2 months releases; one month for committing new stuff, and another month for testing and only bugfixes + looking at our autobuilds to see any regressions. Gün.
Re: [discussion] Release 2.0.65 [the final frontier]
Hi Bill, On 02.07.2013 01:47, wr...@rowe-clan.net wrote: I am not at all concerned whether APR 0.9 is released again or not since folks had years to take that up in our discussions of putting httpd 2.0 to bed, yet nobody so much as suggested a release, nevermind some volunteer to act on it. true; but I thought that most of us probably forgot about that we bundle APR/APU with 2.0.x - like I did; the lack of APR/APU fixes came only to my attention when I was on building the 2.0.65 binaries ... but since nobody else expressed an oppinion about then thats fine, and I shut up. or if you have concurred with the group consensus to let this story end as of Jun 2013. I have. Just did put the NetWare bins up; go ahead and release. Gün.
Re: [VOTE] Release 2.0.65 [the final frontier]
On 28.06.2013 23:28, William A. Rowe Jr. wrote: Candidates are in http://httpd.apache.org/dev/dist/ +/-1 [ ] Release 2.0.65 as the final 2.0 series package TIA! it seems a bit odd to me that we now roll the 2.0.65 final without having APR/APU picking up latest fixes [1][2], making this release hanging around for ever bundled with APR/APU 0.9.x versions which lack latest stuff: Index: CHANGES === --- CHANGES (revision 1170001) +++ CHANGES (working copy) @@ -1,4 +1,24 @@ - -*- coding: utf-8 -*- + +-*- coding: utf-8 -*- +Changes with APR 0.9.21 + + *) configure: Fix detection of O_NONBLOCK inheritance on busy + systems. [Rainer Jung] + + *) apr_time_exp_*() on Windows: Fix error in the tm_yday field of + apr_time_exp_t for times within leap years. PR 53175. + [Jeff Trawick] + + *) Improve platform detection by updating config.guess and config.sub. + [Rainer Jung] + + *) Flush write buffer before truncate call on a file. + [Mladen Turk] + + *) Security: oCERT-2011-003 + Randomise hashes by providing a seed. + [Bojan Smojver, Branko ÄŒibej, Ruediger Pluem et al.] + Index: CHANGES === --- CHANGES (revision 1021610) +++ CHANGES (working copy) @@ -1,4 +1,9 @@ -*- coding: utf-8 -*- +Changes with APR-util 0.9.20 + + *) Improve platform detection for bundled expat by updating + config.guess and config.sub. [Rainer Jung] + we should really also tag release APR/APU 0.9.x, and then bundle these with 2.0.65; and perhaps also announce EOL of 0.9.x branch ... Gün. [1] http://people.apache.org/~fuankg/diffs/apr-0_9_20.diff [2] http://people.apache.org/~fuankg/diffs/apu-0_9_19.diff
Re: [VOTE] Release 2.2.25
On 28.06.2013 23:29, William A. Rowe Jr. wrote: Candidates are in http://httpd.apache.org/dev/dist/ +/-1 [ ] Release 2.2.25 (apr 1.4.8, apr-util 1.5.2) +1 on NetWare.
Re: mod_lua in 2.4 CHANGES
On 28.06.2013 01:03, Rainer Jung wrote: Hi Daniel and/or Günter, can you have a look at the trunk CHANGES file and move the lua items that should now be in 2.4 to the 2.4 CHANGES file? We forgot that when we synced 2.4 with trunk and it would be nice to have them in the 2.4 file before 2.4.5 gets tagged. well, I was lazy and did only mention the few new functions I added in 2.4 after all were backported - so nothing to move :-P but I didnt keep track of the various bugfixes we did ... Gün.
regarding mod_cache_socache ...
Hi, mod_cache_socache also uses different datatypes, here its apr_off_t vs. apr_size_t; at least on 32-bit OS it happens that with LARGE_FILE apr_size_t = int32, but apr_off_t = int64 ... mod_cache_socache.c .\httpd\modules\cache\mod_cache_socache.c(399) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data .\httpd\modules\cache\mod_cache_socache.c(400) : warning C4244: 'function' : conversion from '__int64 ' to 'unsigned int ', possible loss of data .\httpd\modules\cache\mod_cache_socache.c(401) : warning C4244: 'function' : conversion from '__int64 ' to 'unsigned int ', possible loss of data .\build\httpd\modules\cache\mod_cache_socache.c(464) : warning C4244: 'function' : conversion from '__int64 ' to 'unsigned int ', possible loss of data .\httpd\modules\cache\mod_cache_socache.c(465) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data .\httpd\modules\cache\mod_cache_socache.c(808) : warning C4244: 'function' : conversion from '__int64 ' to 'unsigned int ', possible loss of data .\httpd\modules\cache\mod_cache_socache.c(809) : warning C4244: '=' : conversion from '__int64 ' to 'unsigned int ', possible loss of data .\httpd\modules\cache\mod_cache_socache.c(402) : warning C4761: integral size mismatch in argument; conversion supplied .\build\httpd\modules\cache\mod_cache_socache.c(402) : warning C4761: integral size mismatch in argument; conversion supplied .\httpd\modules\cache\mod_cache_socache.c(464) : warning C4761: integral size mismatch in argument; conversion supplied .\httpd\modules\cache\mod_cache_socache.c(808) : warning C4761: integral size mismatch in argument; conversion supplied so this 'possible loss of data' is true, and this might probably be an issue when caching 4GB ... solong, Gün.
Re: svn commit: r1492782 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Hi, ATM I cant get the Java docu stuff working on my new dev box: BUILD FAILED java.lang.StackOverflowError and also I'm short of time to look further into fixing it - therefore I would like to ask someone for some help with the below commit to regenerate the docs + backport this also to 2.4.x ... Thanks! On 13.06.2013 19:50, fua...@apache.org wrote: Author: fuankg Date: Thu Jun 13 17:50:25 2013 New Revision: 1492782 URL: http://svn.apache.org/r1492782 Log: Added new funtions to mod_lua docu. Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_lua.xml?rev=1492782r1=1492781r2=1492782view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_lua.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Thu Jun 13 17:50:25 2013 @@ -716,7 +716,13 @@ local escaped = r:escape(url) -- returns r:unescape(string) -- Unescapes an URL-escaped string: local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5 -local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 amp; 4 + 5' +local unescaped = r:unescape(url) -- returns 'http://foo.bar/1 2 3 amp; 4 + 5' +/highlight + +highlight language=lua +r:construct_url(string) -- Constructs an URL from an URI + +local url = r:construct_url(r.uri) /highlight highlight language=lua @@ -863,7 +869,7 @@ r:state_query(string) -- Queries the ser /highlight highlight language=lua -r:stat(filename) -- Runs stat() on a file, and returns a table with file information: +r:stat(filename [,wanted]) -- Runs stat() on a file, and returns a table with file information: local info = r:stat(/var/www/foo.txt) if info then @@ -872,7 +878,7 @@ end /highlight highlight language=lua -r:regex(string, pattern, [flags]) -- Runs a regular expression match on a string, returning captures if matched: +r:regex(string, pattern [,flags]) -- Runs a regular expression match on a string, returning captures if matched: local matches = r:regex(foo bar baz, [[foo (\w+) (\S*)]]) if matches then @@ -919,6 +925,45 @@ function handle(r) end /highlight +highlight language=lua +r:htpassword(string [,algorithm [,cost]]) -- Creates a password hash from a string. + -- algorithm: 0 = APMD5 (default), 1 = SHA, 2 = BCRYPT, 3 = CRYPT. + -- cost: only valid with BCRYPT algorithm (default = 5). +/highlight + +highlight language=lua +r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode paramter. +/highlight + +highlight language=lua +r:rmdir(dir) -- Removes a directory. +/highlight + +highlight language=lua +r:get_direntries(dir) -- Returns a table with all directory entries. + +-- Return path splitted into components dir, file, ext +function split_path(path) + return path:match((.-)([^\\/]-%.?([^%.\\/]*))$) +end + +function handle(r) + local cwd, _, _ = split_path(r.filename) + for _, f in ipairs(r:get_direntries(cwd)) do +local info = r:stat(cwd .. f) +if info then + local mtime = os.date(fmt, info.mtime / 100) + local ftype = (info.filetype == 2) and [dir] or [file] + r:puts( (%s %s %10i %s\n):format(ftype, mtime, info.size, f) ) +end + end +end +/highlight + +highlight language=lua +r.date_parse_rfc(string) -- Parses a date/time string and returns seconds since epoche. +/highlight + /section section id=loggingtitleLogging Functions/title
Re: svn commit: r1492782 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
On 17.06.2013 23:15, Rainer Jung wrote: On 17.06.2013 18:03, Guenter Knauf wrote: Hi, ATM I cant get the Java docu stuff working on my new dev box: BUILD FAILED java.lang.StackOverflowError and also I'm short of time to look further into fixing it - therefore I would like to ask someone for some help with the below commit to regenerate the docs + backport this also to 2.4.x ... Done. thanks Rainer! Gün.
Re: [Vote] Switch mod_lua in 2.4 to CTR
On 08.06.2013 17:04, Rainer Jung wrote: I suggest to switch mod_lua in 2.4 to CTR mode. [ ] +1: I support this proposal [ ] 0: I don't care [ ] -1: I don't support this proposal, because... +1 Gün.
Re: Proposal: switch mod_lua in 2.4 to CTR
On 07.06.2013 18:26, Rainer Jung wrote: mod_lua is still marked experimental because we did not yet expect it to be complete or the APIs to be stable. So we did expect and wanted to allow incompatible changes. Now that a few of us are working on it I expect it would be useful if backports could be done quicker for some time until we think we have approached stability. So I plan to start a vote an switching mod_lua in 2.4 to CTR. Please let me know your objections if there are any. +1 - I prosed same already some days ago ... Gün.
Re: mod_lua oddities
On 06.06.2013 02:34, Eric Covener wrote: This is a bug in the example and/or the code. If you don't return a HTTP status code, or apache2.OK, the request is declined and handled by the core. I am split between returning 500 or assuming no return value = apache2.OK. thanks Eric! After I added a 'return pache2.OK' to the script it started working on all platforms with absolute path; now only the relative path messing remains ... Gün.
Re: mod_lua oddities
On 06.06.2013 12:48, Eric Covener wrote: What's the expectation on a relative path? ServerRoot? yep
Re: svn commit: r1490290 - /httpd/httpd/trunk/modules/lua/lua_passwd.c
Hi Rüdiger, On 06.06.2013 16:03, rpl...@apache.org wrote: Author: rpluem Date: Thu Jun 6 14:03:28 2013 New Revision: 1490290 URL: http://svn.apache.org/r1490290 Log: * truncpw was allocated from a pool and not via malloc Modified: httpd/httpd/trunk/modules/lua/lua_passwd.c Modified: httpd/httpd/trunk/modules/lua/lua_passwd.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_passwd.c?rev=1490290r1=1490289r2=1490290view=diff == --- httpd/httpd/trunk/modules/lua/lua_passwd.c (original) +++ httpd/httpd/trunk/modules/lua/lua_passwd.c Thu Jun 6 14:03:28 2013 @@ -138,7 +138,6 @@ int mk_password_hash(passwd_ctx *ctx) characters by CRYPT algorithm.); } memset(truncpw, '\0', strlen(pw)); -free(truncpw); } break; #endif /* CRYPT_ALGO_SUPPORTED */ doesnt the same then also apply to ./support/passwd_common.c line 241 ? Gün.
Re: Apache and TProxy
Hi Ali, On 05.06.2013 11:48, Ali Majdzadeh wrote: Hello All please stop embedding links to external components like pictures! This is a usual practice of email harvesters, and triggers spam detection for many readers of this list; if you want to get help here and make sure that your emails get read then best is to post plain text mails. Gün.
Re: mod_lua oddities
On 05.06.2013 08:11, Gregg Smith wrote: Hi folks, The more eyes the better I've been told. Sorry that it's lengthy. x86 VC9 *Release* Build httpd version : 2.4.5-r1489105 mod_lua from trunk at r1487956 Odd results: ServerRoot C:/Apache24A 1. Running scripts fortune.lua or example.lua via URL works. 2. With LuaMapHandler /testlua htdocs/lua/example.lua LuaMapHandler /fortune htdocs/lua/fortune.lua Running fortune.lua via URL 500s example.lua runs fine via URL 3. LuaMapHandler /testlua htdocs/lua/example.lua LuaMapHandler /tellme htdocs/lua/fortune.lua both scripts run fine from URL, so there's some kind of leak where http://localhost/lua/fortune.lua becomes http://localhost/fortune to the server 4. LuaMapHandler /testlua htdocs/lua/example.lua LuaMapHandler /tellme htdocs/lua/fortune.lua http://localhost/tellme http://localhost/testlua error 500 [Tue Jun 04 22:53:30.41 2013] [lua:error] [pid 3984:tid 948] AH01482: Error loading C:/Apache24A/bin/htdocs/lua/example.lua: cannot open C:/Apache24A/bin/htdocs/lua/example.lua: No such file or directory [Tue Jun 04 22:53:30.41 2013] [lua:crit] [pid 3984:tid 948] [client ::1:53940] AH02330: lua: Failed to obtain lua interpreter for handle htdocs/lua/example.lua, referer: http://localhost/lua/ Notice mod_lua is adding /bin to the file location! cannot open C:/Apache24A/bin/htdocs/lua/example.lua This as you can see is not the location I have it set to look for the script per documented configuration rules about relative paths. Interestingly, mod_lua seems to get it right at first it looks then blows up. [Tue Jun 04 22:53:15.543200 2013] [lua:trace1] [pid 3984:tid 948] mod_lua.c(261): [client ::1:53939] AH01472: handling [C:/Apache24A/htdocs/lua/example.lua] in mod_lua, referer: http://localhost/lua/ [Tue Jun 04 22:53:15.543200 2013] [lua:trace2] [pid 3984:tid 948] mod_lua.c(177): [client ::1:53939] AH02313: request handler details: scope: once, file: C:/Apache24A/htdocs/lua/example.lua, func: handle, referer: http://localhost/lua/ [Tue Jun 04 22:53:15.543200 2013] [lua:trace3] [pid 3984:tid 948] mod_lua.c(281): [client ::1:53939] AH01474: got a vm!, referer: http://localhost/lua/ [Tue Jun 04 22:53:15.543200 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1702): [client ::1:53939] AH01487: request_rec-dispatching puts - lua_CFunction, referer: http://localhost/lua/ [Tue Jun 04 22:53:15.543200 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1711): [client ::1:53939] AH01488: request_rec-dispatching method - string, referer: http://localhost/lua/ [Tue Jun 04 22:53:15.543200 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1702): [client ::1:53939] AH01487: request_rec-dispatching parseargs - lua_CFunction, referer: http://localhost/lua/ [Tue Jun 04 22:53:15.543200 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1702): [client ::1:53939] AH01487: request_rec-dispatching puts - lua_CFunction, referer: http://localhost/lua/ [Tue Jun 04 22:53:19.646000 2013] [lua:trace1] [pid 3984:tid 948] mod_lua.c(261): [client ::1:53939] AH01472: handling [C:/Apache24A/htdocs/lua/fortune.lua] in mod_lua, referer: http://localhost/lua/ [Tue Jun 04 22:53:19.646000 2013] [lua:trace2] [pid 3984:tid 948] mod_lua.c(177): [client ::1:53939] AH02313: request handler details: scope: once, file: C:/Apache24A/htdocs/lua/fortune.lua, func: handle, referer: http://localhost/lua/ [Tue Jun 04 22:53:19.646000 2013] [lua:trace3] [pid 3984:tid 948] mod_lua.c(281): [client ::1:53939] AH01474: got a vm!, referer: http://localhost/lua/ [Tue Jun 04 22:53:19.646000 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1692): [client ::1:53939] AH01486: request_rec-dispatching headers_out - apr table, referer: http://localhost/lua/ [Tue Jun 04 22:53:19.646000 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1692): [client ::1:53939] AH01486: request_rec-dispatching headers_out - apr table, referer: http://localhost/lua/ [Tue Jun 04 22:53:19.646000 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1692): [client ::1:53939] AH01486: request_rec-dispatching headers_out - apr table, referer: http://localhost/lua/ [Tue Jun 04 22:53:19.646000 2013] [lua:debug] [pid 3984:tid 948] lua_request.c(1702): [client ::1:53939] AH01487: request_rec-dispatching puts - lua_CFunction, referer: http://localhost/lua/ 5. With: LuaMapHandler /testlua C:/Apache24A/htdocs/lua/example.lua LuaMapHandler /tellme C:/Apache24A/htdocs/lua/fortune.lua Set with full path these 404. http://localhost/tellme http://localhost/testlua 6. Adding LuaRoot LuaRoot htdocs/lua LuaMapHandler /testlua htdocs/lua/example.lua LuaMapHandler /tellme htdocs/lua/fortune.lua http://localhost/tellme http://localhost/testlua Both crash! Guenter has confirmed some of this behavior in Netware, I'll let him chime in on which. yes, I can confirm that LuaMapHandler does not work for me on any platform - tested NetWare, Linux and Windows ... # curl
Re: mod_lua oddities
On 05.06.2013 21:59, Guenter Knauf wrote: yes, I can confirm that LuaMapHandler does not work for me on any platform - tested NetWare, Linux and Windows ... # curl http://localhost/tellme !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title404 Not Found/title /headbody h1Not Found/h1 pThe requested URL /tellme was not found on this server./p /body/html [Thu Jun 06 00:05:12.047987 2013] [lua:trace2] [pid 5740:tid 140544617477888] mod_lua.c(180): [client ::1:56957] AH02313: mapped handler details: scope: once, file: /srv/www/tstlua/fortune.lua, func: handle [Thu Jun 06 00:05:12.049191 2013] [lua:debug] [pid 5740:tid 140544617477888] lua_request.c(1712): [client ::1:56957] AH01486: request_rec-dispatching headers_out - apr table [Thu Jun 06 00:05:12.049216 2013] [lua:debug] [pid 5740:tid 140544617477888] lua_request.c(1712): [client ::1:56957] AH01486: request_rec-dispatching headers_out - apr table [Thu Jun 06 00:05:12.049224 2013] [lua:debug] [pid 5740:tid 140544617477888] lua_request.c(1712): [client ::1:56957] AH01486: request_rec-dispatching headers_out - apr table [Thu Jun 06 00:05:12.049235 2013] [lua:debug] [pid 5740:tid 140544617477888] lua_request.c(1722): [client ::1:56957] AH01487: request_rec-dispatching puts - lua_CFunction [Thu Jun 06 00:05:12.049265 2013] [core:info] [pid 5740:tid 140544617477888] [client ::1:56957] AH00128: File does not exist: /srv/www/htdocs/tellme oh forgot - this was on Linux: Server: Apache/2.5.0-r1489410 (Unix) beside the above some more oddities - displaying modules.cpath shows with mod_lua (mod_lua directive unconfigured): package.cpath=/usrlib/lua/5.2/?.so;/usrlib/lua/5.2/loadall.so;/srv/www/tstlua/?.so; same server, but displaying modules.cpath with a pure Lua CGI: package.cpath=/usr/lib64/lua/5.2/?.so;/usr/lib64/lua/5.2/loadall.so;./?.so (which is the correct path) Gün.
Re: Time for 2.4.5 ??
On 25.05.2013 05:46, Guenter Knauf wrote: Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5 local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5' the function call should here be r:unescape(url) ... another one missing from the docs: r:construct_url(string) -- Constructs an URL from an URI local url = r:construct_url(r.uri) Gün.
Re: why does Header set send lower case header names?
On 01.06.2013 16:39, Reindl Harald wrote: IfModule mod_headers.c Header set X-DNS-Prefetch-Control off /IfModule from the network: x-dns-prefetch-control: off works for me - just tested on Win32 and NetWare with httpd-trunk: curl -I http://localhost:8080 HTTP/1.1 200 OK Date: Sat, 01 Jun 2013 18:34:27 GMT Server: Apache/2.5.0-r1483348 (Win32) OpenSSL/1.0.1e mod_uptime/0.2.0 mod_view/2.2 Accept-Ranges: bytes X-DNS-Prefetch-Control: off Content-Type: text/html what version do you use, and on what OS? And with what software do you check? Have you tried f.e. curl as I did? Günter.
Re: unsubscribe
On 31.05.2013 13:24, Jim Jagielski wrote: C'mon... it's not like we provide list instructions as mail headers for each and every email that goes to this list... oh wait... yeah, indeed we do: ... Reply-To: dev@httpd.apache.org list-help: mailto:dev-h...@httpd.apache.org list-unsubscribe: mailto:dev-unsubscr...@httpd.apache.org List-Post: mailto:dev@httpd.apache.org List-Id: dev.httpd.apache.org Delivered-To: mailing list dev@httpd.apache.org ... Gün.
Re: Time for 2.4.5 ??
Hi Daniel,
On 25.05.2013 05:46, Guenter Knauf wrote:
On 25.05.2013 02:06, Guenter Knauf wrote:
On 24.05.2013 23:45, Daniel Gruno wrote:
That's fine by me, I'm not married to 'sleep' (although I do like a good
nap)
hehe, ok; I look into it soon.
done.
Found another small docu bug:
r:unescape(string) -- Unescapes an URL-escaped string:
local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5
local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5'
the function call should here be r:unescape(url) ...
I have meanwhile all the compiler warnings reduced down to one:
.\lua_request.c(574) : warning C4244: 'return' : conversion from
'apr_off_t' to 'int', possible loss of data
this is a somehwat tricky one, and I'm not sure whats the best way to
fix it; clearly a cast wouldnt help here since r-remaining is
apr_off_t, so a cast to int would indeed be a loss of data ...
so the function needs to return the 64-bit apr_off_t:
Index: lua_request.c
===
--- lua_request.c (revision 1486269)
+++ lua_request.c (working copy)
@@ -569,7 +569,7 @@
return r-useragent_ip;
}
-static int req_remaining_field(request_rec *r)
+static apr_off_t req_remaining_field(request_rec *r)
{
return r-remaining;
}
but then the problem would be shifted to req_dispatch() where we only
have APL_REQ_FUNTYPE_INT - should we add there a new type
APL_REQ_FUNTYPE_INT64? Or do you have a better idea?
Gün.
Re: mod_ssl NPN API rejig (was Re: Intent to revert commit r1332643)
Hi Joe, On 29.05.2013 18:06, Joe Orton wrote: On Wed, May 29, 2013 at 11:37:14AM -0400, Matthew Steele wrote: Oops, yes, RUN_ALL semantics are desired; the misleading API description is my fault, sorry. (I confess I never really understood why RUN_ALL hooks accept both OK and DECLINED values, but then don't actually treat them any differently.) So probably we should update the doc comments. I'd be happy to draft new versions for those if that would be helpful, or not, as you prefer. OK vs DECLINED has always confused me too ;) How does this look? I've specified the behaviour for OK and DONE as return codes for both the callbacks; since the caller doesn't pay attention to errors I've left behaviour undefined for any other values. (Really attached this time) thanks for looking into it! I will test tomorrow; need a rest just now since was the whole day busy at customers; but perhaps Gregg beats me soon ... Gün.
Re: svn commit: r1482918 - in /httpd/httpd/trunk: modules/http/http_filters.c server/protocol.c
Hi Graham,
seems you forgot to add a log number at line 1541:
On 15.05.2013 17:46, minf...@apache.org wrote:
Author: minfrin
Date: Wed May 15 15:46:01 2013
New Revision: 1482918
URL: http://svn.apache.org/r1482918
Log:
core: Stop ap_finalize_request_protocol() and ap_get_client_block() from
silently
swallowing errors from the filter stack, create error buckets and return them
appropriately.
Modified:
httpd/httpd/trunk/modules/http/http_filters.c
httpd/httpd/trunk/server/protocol.c
Modified: httpd/httpd/trunk/modules/http/http_filters.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1482918r1=1482917r2=1482918view=diff
==
--- httpd/httpd/trunk/modules/http/http_filters.c (original)
+++ httpd/httpd/trunk/modules/http/http_filters.c Wed May 15 15:46:01 2013
...
+if (APR_SUCCESS != rv) {
+ap_log_rerror(APLOG_MARK, APLOG_INFO, rv, r, APLOGNO()
+ Error while writing error response);
+}
+
/* if we actually fail here, we want to just return and
* stop trying to read data from the client.
*/
Gün.
Re: Intent to revert commit r1332643
Hi, On 24.05.2013 14:57, Jeff Trawick wrote: NPN is pretty important, granted. I promise to post a patch (or just commit if it is as trivial an issue as it sounds) in the next week to fix the hard link between core and ssl. Maybe I'll mess with the AP-SSL hook issue too. cool! How close does that get you to goodness on Windows, and may I presume there's no desire to revert as long as progress is being made? it was more an attempt by me to kick on discussion again; I feel sometimes that must be done in a drastical way when over one year nothing happend, and discussion just died ;-) so that was kinda last resort - of course if com0ilation breaks no longer all is fine again! Gün.
Re: Time for 2.4.5 ??
On 24.05.2013 14:40, Jim Jagielski wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff ok, after spending a bunch of hours during last weeks with testing mod_lua mainly on Windows I've finally removed my blocking vote from STATUS just now; nevertheless I feel that I did only test half of all the new stuff, and therefore my vote is +0.5 only ... some things which I see as outstanding are: - removal of the export declarations since they are unneeded (I will take a look into this during this weekend if nobody beats me) - removal of some doubled code ( ap_lua_check_request_rec() ) - another docu fix for r:sleep() -- r.sleep(); meanwhile I have a stronger oppinion about this: I believe we should chage all functions to r:function() in order to separate them more clearly from vars like r.filename; further more I believe r.sleep() would be better renamed to r.usleep() taking microseconds instead of having a r.sleep() and then dealing with fractions of seconds - this way also the code would be cleaner and no calculation of the passed-in value needed anymore, just the value would get passed to apr_sleep(). Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... So how do we further proceed with mod_lua? There are certainly some remaining issues, but it just takes too long for only 2 persons to find them all; also I see with current code that it works fine when I compile it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not sure yet if this is an issue with MSVC9 itself, or with the converted projects ...; I think we should now copy over the complete trunk code to 2.4.x branch, and keep the status 'experimental' so that users are warned that directives, functions, etc. might change even with an otherwise stable release branch; hopefully then when more users play with mod_lua we will make faster progress with finding any further issues ... also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. Gün.
Re: Whither Windows (Was: Re: Intent to revert commit r1332643)
Hi Jim, On 24.05.2013 14:52, Jim Jagielski wrote: For me, I wouldn't want to stunt httpd development for every other platform we care about simply because it breaks Windows. But it's not just my decision, 'natch. well, for me its no reason to just accept every code as long as it compiles on *nix platforms regardless of design flaws; also we could easily fix the stuff so that Windows would compile again even with the design flaw, but that's not what Bill would accept IIUC, and not what I would like to do ... finally what I was mainly after was kicking on discussion again about how to fix it correctly, and thats now in progress ... ;-) Gün.
httpd buildbot
I dont know who has access / maintains the httpd buildbot, but I would like to have it build with maintainer mode; this could be useful to avoid that code we dont want slips in, f.e. var declarations after statements ... Gün.
Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))
On 24.05.2013 21:37, Ben Reser wrote: The build system should be able to compile with the major tool chains, nobody expects to know how to work around weird autoconf, make, gcc, etc quirks on Linux. I don't say this to be dismissive of anyones contributions but just to point out that producing Windows builds with a modern toolchain is not simple. yeah ...; and from what I see our project files are already broken even when not converted and used directly with MSVC6, f.e. when doing a release build a bunch of files land in the debug folder, and finally at linking stage it breaks ... probably we should think about moving either to plain Nmakefiles (as Pierre Joy also suggested), or add a Cmake build system; for me SCon is no alternative since I saw it too often already fail on modern Linux boxes (with other projects), so I have no hope that it works any better on Windows ... and regarding trunk: AFAICT there are no improvements (what I mentioned above was with trunk) ... Gün.
Re: Time for 2.4.5 ??
On 24.05.2013 22:14, William A. Rowe Jr. wrote: There are several others of us, but large patch sets are difficult to incorporate in our day-to-day build trees. What about a sandbox of all of the proposed deltas, either just the modules/lua/ branch or the entire tree if that isn't realistic. It's preferable to just svn switch that branch to the sandbox for some more active eyeballs looking at the thing. ATM I think this is not needed - from what I tested during past weeks the current trunk code is at least as good / bad as what is already in 2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me due to various bug fixes beside the added new stuff. Gün.
Re: Time for 2.4.5 ??
Hi Daniel, On 24.05.2013 23:45, Daniel Gruno wrote: I can only say +1 from me, we need consistency here :) great! That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... I've not looked in APR, but I assume this is something supported in there? Perhaps if you could come up with a sketch/mock api, we could get started on this? yes, see the apr_dbm.h header; SDBM is the only database we allways have even without any driver or external libs; it can be used f.e. for password storage (htdbm.c), and I think mod_dav makes use of it for its lock database; as usage example might serve mod_authn_dbm.c ... Gün.
Re: Time for 2.4.5 ??
Hi Daniel, On 25.05.2013 02:06, Guenter Knauf wrote: On 24.05.2013 23:45, Daniel Gruno wrote: That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. done. Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5 local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5' the function call should here be r:unescape(url) ... Gün.
Intent to revert commit r1332643
Hi all, I will revert the changes done with: http://svn.apache.org/viewvc?view=revisionrevision=1332643 after 72 hours if nobody is going to fix the stuff properly for Windows since I'm tired of always copying mod_ssl over from 2.4.x branch in order to get a working mod_ssl with trunk. Reasons: 1) within last 12 months there was no attempt made to fix the issues which wrowe mentioned in this thread [1] - instead discussion died 2) a suggestion to fix the issue [2] was not applied due to the concerns wrowe brought up, and to which I agree. 3) the same issue also causes a stalled backport in 2.2.x STATUS [3] for the last 12 months [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3C20130205115224.33547872@hub%3E [2] http://mail-archives.apache.org/mod_mbox/httpd-dev/201302.mbox/%3c510d8293.8010...@gknw.net%3E [3] http://svn.apache.org/viewvc?view=revisionrevision=1333501 I believe that one year in trunk without further review is long enough, and if someone wants to continue working on it its easy enough to checkout the last revision before removal. Gün.
Re: svn commit: r1480871 - /httpd/httpd/trunk/modules/lua/lua_request.c
Hi all, something went wrong with this commit: svn ci modules\lua Sendingmodules\lua\lua_request.c Transmitting file data . Committed revision 1480871. Warning: post commit FS processing had error: Couldn't open rep-cache database and then: svn up svn: A reported revision is higher than the current repository HEAD revision. Perhaps the repository is out of date with respect to the master repository? also this revision doesnt show up with viewvc: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_request.c?view=log anyone an idea what went wrong? Gün. On 10.05.2013 05:38, fua...@apache.org wrote: Author: fuankg Date: Fri May 10 03:37:06 2013 New Revision: 1480871 URL: http://svn.apache.org/r1480871 Log: Revert part of r1476482 which disabled fractions of seconds with r.sleep(). Modified: httpd/httpd/trunk/modules/lua/lua_request.c Modified: httpd/httpd/trunk/modules/lua/lua_request.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_request.c?rev=1480871r1=1480870r2=1480871view=diff == --- httpd/httpd/trunk/modules/lua/lua_request.c (original) +++ httpd/httpd/trunk/modules/lua/lua_request.c Fri May 10 03:37:06 2013 @@ -1574,7 +1574,7 @@ static int lua_ap_sleep(lua_State *L) apr_interval_time_t msec; luaL_checktype(L, 1, LUA_TNUMBER); -msec = (lua_tointeger(L, 1) * 100); +msec = (lua_tonumber(L, 1) * 100); apr_sleep(msec); return 0; }
Re: URL scanning by bots
André, On 02.05.2013 10:22, André Warnier wrote: I'd like to say that I do agree with you, in that there are already many tools to help defend one's servers against such scans, and against more targeted attacks. I have absolutely nothing /against/ these tools, and indeed installing and configuring such tools on a majority of webservers would do much more for Internet security in general, than my proposal ever would. But at the same time, there is the rub, as you say yourself : All that is missing is enough people configuring their servers as you propose. These tools must be downloaded separately, installed, configured and maintained, all by someone who knows what he's doing. isnt that one of the core issues - that folks who dont know what they do run a webserver? And then, shouldnt these get punished with being hacked so that they try to learn and finally *know* what they do, and do it right next time? ;-) And this means that, in the end (and as the evidence shows), only a tiny minority of webservers on the Internet will effectively set up one of those, and the vast majority of webservers will not. And among the millions of webservers that don't, there will be enough candidates for break-in to justify these URL scans, because URL-scanning at this moment is cheap and really fast. In contrast, my proposal is so simple from an Apache user point of view, that I believe that it could spread widely, without any other measure than configuring it by default in the default Apache distribution (and be easily turned off by whoever decides he doesn't want it). If my purpose was merely to shield my own servers, then I would not spend so much time trying to defend the merits of this proposal. Instead, I would install one of these tools and be done with it. I am not doing it, because on the one hand my servers - as far as I know of course - do not exhibit any of these flaws which they are scanning for, and on the other hand because these traces in the logs provide me with information about how they work. I apologise if I repeat myself, and if I am perceived as hot sometimes. It may be because of a modicum of despair. I don't know what I was expecting as a reaction to this proposal, but I am disappointed - maybe wrongly so. I was ready for criticism of the proposal, or for someone proving me wrong, on the base of real facts or calculations. But what I am mostly seeing so far, are objections apparently based on a-priori opinions which my own factual observations show to be false. Not only my own though : the couple of people here who have contributed based on a real experience with real servers, do not seem to contradict my own findings. So I am not totally despairing yet. But I am a bit at a loss as to what to do next. I could easily enough install such a change on my own servers (they are all running mod_perl). But then, if it shows that the bots do slow down on my servers or avoid them, it still doesn't quite provide enough evidence to prove that this would benefit the Internet at large, does it ? No. But you wrote above that its not your intention to protect yourself and your servers, but more that you want to cure the world and enable to run webservers by 'folks who dont know what they do', or??? Ok, 1st lets again assume that you really get here enough httpd developers who support your idea, and we get finally such functionality into httpd, and lets also assume the even more unlikely case that you get us to make this the default - but what do you expect when this will happen? *If* this really happens then this would go into trunk, that means unreleased code. Currently we have two maintained release branches, that are 2.2.x and 2.4.x, where the 1st 2.4.x release happened about 15 months ago. I dont know numbers, but I assume that currently after 15 months only 1 or 2 % have upgraded to 2.4.x, and the vast majority is still running the 2.2.x releases, or even still 2.0.x. Maybe that within the next 9 months another 2-3% will upgrade, so that we have probably 5% running latest version 2 years after 1st release. Now lets further assume that the httpd project decides to release a 2.6.x within these next 9 months (which seems very unlikely, but who knows ...) which contains your slow-down code, and now imagine self how long from now on it would take until your slow-down code would be in use by default of at least 10%? 3 years, 4 years, ?? When would it show up an effect? After 5 years? And are the bots in 5 years still the same as nowadays? Furthermore, unless we are forced by security issues, there's no reason to break our policies and backport such a feature to the 2.4.y and 2.2.x branches yeah, now I imagine that I did you totally disappoint with the above, but hey, thats the reality how things work with the httpd project ... Ok, now let me throw in some things which I can think of what you still can do in order to make the world's internet better within the next 5
apache_pb*.* - again
Hi Daniel, I think you did the last revisions of these pics, so I address this directly to you ... it just came to my attention that the apache_pb*.gif look not so fine as the apache_pb*.png ones: https://www.apachehaus.net/apache_pb/ it looks to me that probably there's some font anti aliasing missing; is it possible that you missed that when you created the gifs? Gün.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
On 24.04.2013 00:18, Guenter Knauf wrote: and two more things: 1) I found with my script that there is also a table apr_table created with methods get and set but its not yet documented 2) I wonder why we do export some functions from mod_lua, and what could make use of these? Gregg kindly just tested without those exports, and it still works fine; so seems that Windows doesnt need them either ... another thing I came over: 3) it would be nice if we would do a changedir to the location of the calling script so that its easily possible to use other files in the same dir - I've not yet checked if that should happen, but at least on NetWare where I was testing it does not chdir to the script's dir ... Gün.
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Hi Daniel, On 20.04.2013 08:58, Daniel Gruno wrote: Thanks for the invaluable help, it's really good knowing there's someone else taking such an interest in this project! :) I hope that someday we can shed mod_lua of its experimental status and people won't think me a crazy person for recommending it left and right ;) naa, I find the module useful too for all sorts of smaller tasks as well as special httpd things which otherwise can only be done with a C module I believe ... now since I looked a bit at the code here and there I think there are some things which we should fix over the next months ... 1) the code formatting is not yet at our standard 2) the 'apache2' module does pollute the global table, and at 1st glance with my limited Lua experience I dont see why this happens; I've tested with other dynamically loaded modules like geoip, socket and apr (yeah, there exists a *very* *great* APR binding! [1]), and they all only create their own table and nothing global; it would be nice if we could either teach the apache2 module to behave same, or at least make it prelinked/preloaded and let it only plug in when enabled via 'require'. See attached script which shows what I mean ... 3) Since there exists a well done and well functioning APR binding we should probably consider to add some code to mod_lua so that its possible to prelink/preload this APR binding once at module start instead of loading it from every script again and again ... if we would agree on that we could even ditch a bunch of the recent APR adds, thus making mod_lua itself cleaner / smaller again + we would get almost the full power of APR into mod_lua ... Gün. [1] http://peterodding.com/code/lua/apr/ --[[ Check the package tables --]] --[[ This is the default method name for Lua handlers, see the optional function-name in the LuaMapHandler directive to choose a different entry point. --]] function handle(r) local function print(...) r:puts(... .. \n) end r.content_type = text/plain --local apr = require apr --local geoip = require geoip r:puts( (package.path=%q\n):format(package.path) ) r:puts( (package.cpath=%q\n):format(package.cpath) ) print(\n* Contents of table package:) for k, v in pairs(package) do print( (%s=%q):format(k, tostring(v)) ) end print(\n* Contents of table package.loaded:) for k, v in pairs(package.loaded) do print( (%s=%q):format(k, tostring(v)) ) end print(\n* Contents of table package.preload:) for k, v in pairs(package.preload) do print( (%s=%q):format(k, tostring(v)) ) end print(\n* Contents of table package.loaders:) for k, v in pairs(package.loaders) do print( (%s=%q):format(k, tostring(v)) ) end print( (\npackage.loaded.version=%q):format(package.loaded.version) ) print( (\napache2.version=%q):format(tostring(apache2.version)) ) end
Re: svn commit: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
On 23.04.2013 23:49, Guenter Knauf wrote: Hi Daniel, On 20.04.2013 08:58, Daniel Gruno wrote: Thanks for the invaluable help, it's really good knowing there's someone else taking such an interest in this project! :) I hope that someday we can shed mod_lua of its experimental status and people won't think me a crazy person for recommending it left and right ;) naa, I find the module useful too for all sorts of smaller tasks as well as special httpd things which otherwise can only be done with a C module I believe ... now since I looked a bit at the code here and there I think there are some things which we should fix over the next months ... 1) the code formatting is not yet at our standard 2) the 'apache2' module does pollute the global table, and at 1st glance with my limited Lua experience I dont see why this happens; I've tested with other dynamically loaded modules like geoip, socket and apr (yeah, there exists a *very* *great* APR binding! [1]), and they all only create their own table and nothing global; it would be nice if we could either teach the apache2 module to behave same, or at least make it prelinked/preloaded and let it only plug in when enabled via 'require'. See attached script which shows what I mean ... 3) Since there exists a well done and well functioning APR binding we should probably consider to add some code to mod_lua so that its possible to prelink/preload this APR binding once at module start instead of loading it from every script again and again ... if we would agree on that we could even ditch a bunch of the recent APR adds, thus making mod_lua itself cleaner / smaller again + we would get almost the full power of APR into mod_lua ... Gün. [1] http://peterodding.com/code/lua/apr/ and two more things: 1) I found with my script that there is also a table apr_table created with methods get and set but its not yet documented 2) I wonder why we do export some functions from mod_lua, and what could make use of these? But then again this is only a Lua newbie question, and I dont know enough about the load process of mod_lua specially on Windows with its external dependency to the Lua DLL and how this exactly works, probably these exports are needed for Windows? Gün.
Re: svn commit: r1469744 - in /httpd/httpd/trunk: docs/manual/mod/mod_lua.xml modules/lua/lua_request.c modules/lua/lua_request.h
Hi Daniel, On 19.04.2013 10:46, humbed...@apache.org wrote: Author: humbedooh Date: Fri Apr 19 08:46:28 2013 New Revision: 1469744 URL: http://svn.apache.org/r1469744 Log: Remove lua_ap_banner, as it's no longer being used. Add ivm_get/ivm_set for Inter-VM data transfer. This allows multiple VMs across a process to share data without having to resort to external databases or filesystems. This is a work in progress, and I have yet to work out a proper way of resetting a variable without causing a memory leak (this could be done by allocating a new pool for each object, but I'm trying to see if there's a more efficient way). Comments, ideas etc are most welcome. please, in the future, make 2 separate commits for things like that. The 1st part is a simple removal of dead code, while the 2nd introduces a new feature, so they are not related. thanks, 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, 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 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 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
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: r1469852 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Daniel, On 19.04.2013 16:31, humbed...@apache.org wrote: Author: humbedooh Date: Fri Apr 19 14:31:51 2013 New Revision: 1469852 URL: http://svn.apache.org/r1469852 Log: s/r:/r./ Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_lua.xml?rev=1469852r1=1469851r2=1469852view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_lua.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Fri Apr 19 14:31:51 2013 @@ -843,9 +843,9 @@ r:custom_response(404, Baleted!) /highlight highlight language=lua -r:exists_config_define(string) -- Checks whether a configuration definition exists or not: +r.exists_config_define(string) -- Checks whether a configuration definition exists or not: -if r:exists_config_define(FOO) then +if r.exists_config_define(FOO) then r:puts(httpd was probably run with -DFOO, or it was defined in the configuration) end /highlight that was only 1st half; r:strcmp_match() fix is missing ... BTW. whats about r:started()? Is this needed to be a function, or can we change that too into a var like r.banner? Its still double listed: as var in the request_rec block, and as function below 'Built in functions' ... Gün.
Re: absolute vs. relative paths
On 02.03.2013 04:19, Guenter Knauf wrote: Hi all, in httpd-ssl.conf.in we use always @exp_ for all paths like f.e. @exp_sysconfdir@ and @exp_logfiledir@ while in httpd.conf.in we use @rel_sysconfdir@ and @rel_logfiledir@ - is there any reason for this difference? Any objections for changing those in httpd-ssl.conf.in to relative paths? since nobody replied within 1.5 months I'm going to change to relative later. Gün.
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: r1467730 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
Hi Daniel, On 14.04.2013 08:47, humbed...@apache.org wrote: Author: humbedooh Date: Sun Apr 14 06:47:22 2013 New Revision: 1467730 URL: http://svn.apache.org/r1467730 Log: fix regex documentation for mod_lua Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Modified: httpd/httpd/trunk/docs/manual/mod/mod_lua.xml URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_lua.xml?rev=1467730r1=1467729r2=1467730view=diff == --- httpd/httpd/trunk/docs/manual/mod/mod_lua.xml (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_lua.xml Sun Apr 14 06:47:22 2013 @@ -864,12 +864,19 @@ end /highlight highlight language=lua -r:regex(string, pattern) -- Runs a regular expression match on a string, returning captures if matched: +r:regex(string, pattern, [flags]) -- Runs a regular expression match on a string, returning captures if matched: -local matches = r:regex(foo bar baz, foo (\w+) (\S*)) +local matches = r:regex(foo bar baz, [[foo (\w+) (\S*)]]) if matches then r:puts(The regex matched, and the last word captured ($2) was: .. matches[2]) end + +-- Example ignoring case sensitivity: +local matches = r:regex(FOO bar BAz, [[(foo) bar]], 1) + +-- Flags can be a bitwise combination of: +-- 0x01: Ignore case +-- 0x02: Multiline search /highlight highlight language=lua thanks very much for showing this very cool auto escaping trick! I wasnt aware of it, and this makes a regex a lot more readable! Gün.
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
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 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 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
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 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
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.
Re: mod_macro… backport to 2.4
Am 10.03.2013 23:24, schrieb Igor Galić: +1 - Original Message - On 09/03/2013 17:20, Jim Jagielski wrote: I've proposed copying/backporting mod_macro to 2.4 ! +1 Issac if you and the others would vote in STATUS instead then it would already be done ;-) Gün.
Re: Proposed Lua backport for 2.4
Am 08.03.2013 17:32, schrieb Daniel Gruno: I've just proposed a rather large backport of all the Lua stuff we have in trunk, I hope you'll take a look at it. to me it seems to make more sense to just copy over the trunk version to 2.4 branch ... Gün.
Re: Proposed Lua backport for 2.4
Am 08.03.2013 19:15, schrieb Daniel Gruno: On 03/08/2013 07:12 PM, Guenter Knauf wrote: Am 08.03.2013 17:32, schrieb Daniel Gruno: I've just proposed a rather large backport of all the Lua stuff we have in trunk, I hope you'll take a look at it. to me it seems to make more sense to just copy over the trunk version to 2.4 branch ... Gün. That is also what the proposed backport does - it's one big diff of what separates 2.4 and trunk, hence the proposal saying 'sync' ;) I'm sorry if that was unclear from my email. naa, your mail was clear so far, but I saw the backport proposal with the bunch of single links :-P but now I think thats only to make clear on what commits the sync is based ... Gün.
Re: svn commit: r1451633 - in /httpd/httpd/trunk: include/ap_mmn.h modules/proxy/mod_proxy.h modules/proxy/proxy_util.c
Am 02.03.2013 15:12, schrieb Jim Jagielski: Is there any way you could add the #ifdef stuff? Since I lack a Windows and/or NetWare system, it would be better, I think, if someone who did actually fixed this instead of us simply removing it, and the person who fixed it was able to test the fix :) sure ... 1st it breaks here: CC proxy_util.c ### mwccnlm Compiler: #File: proxy_util.c # - #2405: const socklen_t addrlen = APR_OFFSETOF(struct sockaddr_un, sun_path) # Error: ^^^ # ';' expected # Too many errors printed, aborting program this is because it should be apr_socklen_t; but when I fix this then next is with the struct sockaddr_un ... I've just ifdef'd this problemaric function which makes proxy_util.c compile again for NetWare; lets see what Gregg says for Windows ... http://svn.apache.org/r1451921 Gün.
Re: svn commit: r1451478 - /httpd/httpd/trunk/server/util_script.c
Hi Christophe, Am 01.03.2013 08:00, schrieb Christophe JAILLET: To quick... you can fix the svn log with: svn propedit -r 1451478 --revprop svn:log Gün.
Re: svn commit: r1451633 - in /httpd/httpd/trunk: include/ap_mmn.h modules/proxy/mod_proxy.h modules/proxy/proxy_util.c
Hi Jim, Am 01.03.2013 17:21, schrieb j...@apache.org: Author: jim Date: Fri Mar 1 16:21:49 2013 New Revision: 1451633 URL: http://svn.apache.org/r1451633 Log: Add in rough uds support (Bugx 54101) from Blaise Tarrblaise.t...@gmail.com Modified: httpd/httpd/trunk/include/ap_mmn.h httpd/httpd/trunk/modules/proxy/mod_proxy.h httpd/httpd/trunk/modules/proxy/proxy_util.c please revert this - it breaks winsock platforms which lack support for unix sockets and sockaddr_un (Windows as well as NetWare when build with winsock). If we need this then we must either move that stuff into a separate unix-only file or ifdef everything related to unix sockets with #if APR_HAVE_SYS_UN_H ... Gün.
absolute vs. relative paths
Hi all, in httpd-ssl.conf.in we use always @exp_ for all paths like f.e. @exp_sysconfdir@ and @exp_logfiledir@ while in httpd.conf.in we use @rel_sysconfdir@ and @rel_logfiledir@ - is there any reason for this difference? Any objections for changing those in httpd-ssl.conf.in to relative paths? Gün.
Re: Potential NULL pointer deference in module/arch/netware/mod_nw_ssl.c
Hi Christophe,
Am 25.01.2013 23:26, schrieb Christophe JAILLET:
cppCheck complains about a potential NULL pointer deference in
module/arch/netware/mod_nw_ssl.c
In function 'ssl_io_filter_Upgrade' we have, line 1165 :
if (r) {
...
}
else {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server, APLOGNO(02131)
... ^_
}
If we get here, r is NULL.
Moreover, r- has already been used before in the function. Should r be
NULL, we would already have crashed.
I'm not sure of the way to fix it and have no way to test it, so I just
report it here for your attention.
I think we should either:
- rearrange the code in order to test for r==NULL at the beginning
- just have an ASSERT at the beginning of the function
- drop the 'if/else' if the else case can not happen
thanks for pointing this out. I've just committed a fix:
http://svn.apache.org/viewvc?rev=1443558view=rev
Gün.
Re: [Vote] Overhaul modules.apache.org
Am 25.01.2013 14:21, schrieb Daniel Gruno: Vote [ ] +1: I support this proposal [ ] 0: I don't care [ ] -1: I don't support this proposal, because... +1 Gün.
Re: svn commit: r1431215 - /httpd/httpd/branches/2.4.x/STATUS
Hi Daniel, Am 10.01.2013 10:34, schrieb Daniel Gruno: Can you provide me with the errors that it produces, or some tips on how I can possibly run this compiler on my own computer? Otherwise, I really don't know what to do here - the bindings work fine on all the machines I've tested them on. meanwhile all clarfied; I was writing the mail to you just after I did mention the prob in STATUS; just wanted to avoid that the backport takes place without a workaround. Thanks for your quick coding! Gün.
Re: [VOTE] accept mod_macro as standard module in httpd
Am 03.01.2013 03:06, schrieb Eric Covener: I was preparing the IP clearance forms and noticed our original vote thread was more of a discussion. I wanted to record a formal vote here so I can link to it. Pending IP clearance... [+1] accept mod_macro as a standard module and responsibility for its maintenance [ +/- 0] don't care won't help [ -1] don't accept mod_macro as a standard module +1 Gün.
Re: svn commit: r1424723 - /httpd/httpd/trunk/modules/lua/lua_request.c
Hi Daniel, Am 20.12.2012 22:52, schrieb humbed...@apache.org: Author: humbedooh Date: Thu Dec 20 21:52:03 2012 New Revision: 1424723 URL: http://svn.apache.org/viewvc?rev=1424723view=rev Log: mod_lua: Fix multipart post parsing, so it doesn't include random bytes at the end. Modified: httpd/httpd/trunk/modules/lua/lua_request.c Modified: httpd/httpd/trunk/modules/lua/lua_request.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_request.c?rev=1424723r1=1424722r2=1424723view=diff == --- httpd/httpd/trunk/modules/lua/lua_request.c (original) +++ httpd/httpd/trunk/modules/lua/lua_request.c Thu Dec 20 21:52:03 2012 @@ -19,6 +19,7 @@ #include util_script.h #include lua_apr.h #include scoreboard.h +#include lua_dbd.h what's that? probably non-intended commit? ### mwccnlm Compiler: #File: lua_request.c # -- # 22: #include lua_dbd.h # Error: ^ # the file 'lua_dbd.h' cannot be opened # Too many errors printed, aborting program User break, cancelled... Gün.
Re: [PATCH] Install cache_common.h as needed by mod_cache.h
Am 17.12.2012 12:36, schrieb Graham Leggett: I've applied it to trunk, and proposed it for backport for v2.4. Hopefully this should be quick to evaluate. it did too quick so I couldnt add follow-up r1422879 to the proposal ... so now I did just commit r1422880 which fixes same for NetWare and Windows. Gün.
Re: svn commit: r1421184 - in /httpd/httpd/branches/2.4.x/docs/cgi-examples: printenv.vbs printenv.wsf
Hi Jeff, Am 15.12.2012 15:00, schrieb Jeff Trawick: On Thu, Dec 13, 2012 at 5:04 AM, fua...@apache.org mailto:fua...@apache.org wrote: Author: fuankg Date: Thu Dec 13 10:04:51 2012 New Revision: 1421184 URL: http://svn.apache.org/viewvc?rev=1421184view=rev http://svn.apache.org/viewvc?rev=1421184view=rev Log: Added Windows CGI samples. Added: httpd/httpd/branches/2.4.x/docs/cgi-examples/printenv.vbs (with props) httpd/httpd/branches/2.4.x/docs/cgi-examples/printenv.wsf (with props) I don't understand why we ship this. If some Windows user wants to find out how to write a CGI script in yet another language they can bing it. We have had a couple of very basic examples from the dark ages of the web, and that is MUCH more than enough IMO, particularly since these particular examples are information leaks as soon as somebody enables them. my motivation for these was that the .vbs is like a counterpart to test-cgi, and for the .wsf BZ 51359 to show that we dont need another shebang test in the code. These samples are in-active same as printenv and test-cgi (no active shebang), and if we trust that a Unix admin knows what he does when he activates them why dont we trust a Windows admin too? If you think those samples are bad remove them again, but then please also remove printenv and test-cgi which are basically same. Gün.
Re: svn commit: r1421184 - in /httpd/httpd/branches/2.4.x/docs/cgi-examples: printenv.vbs printenv.wsf
Hi Jeff, Am 17.12.2012 16:00, schrieb Jeff Trawick: Here's a compromise. Use 2.4.x/STATUS to see if you get two more votes to add the two new CGIs to the 2.4.x install. If two other people agree, I'll be quiet. I know these files are under docs, but changing code that gets installed should be voted on. (Even a recent tweak to printenv went through STATUS.) yes, and for this reason up to now I didnt yet change Makefile.win ;-) http://svn.apache.org/viewvc?view=revisionrevision=1422982 I don't think avoiding adding these new features requires removing the existing, similar ones, though I'm +1 for removing the existing ones from trunk. I'm -1 for removing any samples cause I believe they are useful for 1st testing of CGIs; but if we are going to remove them then I would like to create a cgi-samples folder in svn tree and collect there these samples and probably some more, and provide them also for download. Why can't a tiny example in the documentation show what is needed to have a script that httpd can execute? The Windows platform documentation has a few comments about CGIs and the CGI tutorial documentation has a tiny amount of Windows information. Somewhere in there is a reasonable place to document any Windows-specific issues in this area. probably this is a good place; though I'm not that good with docu - maybe Daniel has the mood to give it a try? Gün.
Re: svn commit: r1420377 - in /httpd/httpd/trunk: docs/manual/mod/mod_lua.xml modules/lua/lua_apr.c modules/lua/lua_apr.h modules/lua/mod_lua.c
Am 12.12.2012 22:44, schrieb Marion Christophe JAILLET:
Here are a few things triggered by cppcheck.
Le 11/12/2012 21:08, humbed...@apache.org a écrit :
Author: humbedooh
Date: Tue Dec 11 20:08:24 2012
New Revision: 1420377
URL: http://svn.apache.org/viewvc?rev=1420377view=rev
Log:
mod_lua: Add a lot of core httpd/apr functionality to mod_lua
(such as regex matching, expr evaluation, changing/fetching server
configuration/info - see docs for a complete list).
This also includes a bunch of automatically scraped functions, which
may or may not be super useful.
Comments appreciated as always, especially on the more hacky bits.
Modified: httpd/httpd/trunk/modules/lua/lua_apr.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_apr.c?rev=1420377r1=1420376r2=1420377view=diff
==
--- httpd/httpd/trunk/modules/lua/lua_apr.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_apr.c Tue Dec 11 20:08:24 2012
I've put the parsed file on:
http://people.apache.org/~jailletc36/lua_apr.html
Check it from there. Things noticed by cppcheck are red-marked.
Except the 'The scope of the variable '...' can be reduced' that can be
ignored, all the other remarks are relevant.
Especially:
a useless apr_pcalloc (line 249)
a out of bound access (line 321) -- I don't know if Rsha1 should be
[20] or if the loop should be limited to 16
this seems to be a cut and paste error from lua_apr_md5
a uninitialized variable (line 430)
beside these probs there are type mismatches which break strict compilers:
AR obj_release/lua.lib
CC mod_lua.c
CC lua_apr.c
### mwccnlm Compiler:
#File: lua_apr.c
# --
# 278: apr_md5_final(digest.chr, md5);
# Error:^
# illegal implicit conversion from 'char[16]' to
# 'unsigned char *'
# Too many errors printed, aborting program
User break, cancelled...
make[2]: *** [obj_release/lua_apr.o] Error 2
CC lua_config.c
CC lua_request.c
### mwccnlm Compiler:
#File: lua_request.c
# --
# 230: if (lua_read_body(r, data, size) != OK) {
# Error: ^
# illegal implicit conversion from 'unsigned int *' to
# 'long long *'
# Too many errors printed, aborting program
User break, cancelled...
make[2]: *** [obj_release/lua_request.o] Error 2
Daniel, please check the used types more carefully and either change
them or cast.
Gün.
Re: svn commit: r1420377 - in /httpd/httpd/trunk: docs/manual/mod/mod_lua.xml modules/lua/lua_apr.c modules/lua/lua_apr.h modules/lua/mod_lua.c
Hi Daniel, Am 14.12.2012 11:17, schrieb Daniel Gruno: Thanks for the heads up, guys! I didn't receive Christophe's email, which is why I didn't put these fixes up till now. I will try to use that cppcheck program in the future, it seems very nice, and catches some things that my regular compiler warning settings don't. So thanks for that as well :) you can also use maintainer mode when compiling which adds a bunch of gcc flags which might spot some more issues where a normal build doesnt even warn about. BTW. on topic there's another small issue which you introduced a while back (and it got even backported to 2.4.x already): http://svn.apache.org/viewvc?view=revisionrevision=1365539 it makes no sense to set this define in mod_lua.h - it is still required to build liblua 5.2 with the same define - otherwise you will get linkage errors: ### mwldnlm Linker Error: # Undefined symbol: luaL_openlib in # lua_apr.o ### mwldnlm Linker Error: # Undefined symbol: luaL_openlib in # lua_config.o ### mwldnlm Linker Error: # Undefined symbol: luaL_openlib in # lua_config.o ### mwldnlm Linker Error: # Undefined symbol: luaL_openlib in # lua_request.o ### mwldnlm Linker Error: # Undefined symbol: luaL_openlib in # lua_request.o ### mwldnlm Linker Error: # Undefined symbol: luaL_openlib in # lua_request.o so IMO the right solution would be to introduce a check for luaL_openlib in config.m4 and disable the module if not present, and if present then set the LUA_COMPAT_ALL via CFLAGS from config.m4 ... Gün.
Re: Volunteers to drive an MSI build
Hey folks, Am 27.11.2012 19:13, schrieb Eric Covener: On Tue, Nov 27, 2012 at 12:59 PM, Igor Galići.ga...@brainsware.org wrote: just to revive this thread again, here's a current comment thread to our documentation on: http://httpd.apache.org/docs/2.2/platform/windows.html#comment_502 There's a couple of things to take away from this: * We made no announcements (on our website) that we're essentially dropping Windows support with 2.4 (until further notice) For posterities sake -- we haven't dropped Windows support. There just aren't (currently) contributed binaries or an installer posted on our website. A note would be nice, binaries would be nicer, and an installer would probably be the nicest. well, I cant really get this now; I psoted here 2 times, and Gregg did post self: we have binaries available - just not msi but exe installer; and Gregg has even 64-bit versions - why dont we get some feedback about if we should put them out into release folder?? I believe these binaries are good enough to be released, and for the installer I'd say: we change the default path to c:\apache24 which is less trouble to handle on Vista and up, and see what we get on feedback of the users ... I would even be fine with only a zip archive with a batch file or script for fixing up paths in the conf file and creating a service, and perhaps we should offer that too ... the only point to resolve is that Gregg cant do the releases self but needs a PMC for signing and putting up the artifacts - but I'm willing to assist with that once we get some agreement to put his stuff up. Gün.
Re: mod_macro into apache ?
Am 11.11.2012 09:57, schrieb Fabien: I have developed and maintained a small module called mod_macro since 1998. It is currently available at: http://people.apache.org/~fabien/mod_macro/ I would like to donate the code so that it could be integrated with apache as a standard module. +1 Gün.
Re: Volunteers to drive an MSI build
Am 12.11.2012 17:45, schrieb Issac Goldstand: but we really need something. I know that Gregg has 'something' which is not MSI but an EXE installer, but it works, and I asked already a while back if we should push this out, but there was no further interest / agreement here :-( Gregg, can you perhaps put up at p.a.o what you have so far so that others can take a look and test? Gün.
Re: Volunteers to drive an MSI build
Am 14.11.2012 12:53, schrieb Guenter Knauf: Am 12.11.2012 17:45, schrieb Issac Goldstand: but we really need something. I know that Gregg has 'something' which is not MSI but an EXE installer, but it works, and I asked already a while back if we should push this out, but there was no further interest / agreement here :-( Gregg, can you perhaps put up at p.a.o what you have so far so that others can take a look and test? oh, and please also post a summarize of what we discussed about default location (system drive root vs 'Program Files') because of the right issues with Vista and up ... Gün.
Re: Help reqd. for httpd-2.4.2
Hi Jitesh, Am 10.10.2012 16:24, schrieb Jitesh Verma: We are able to access the box's GUI/Applets with Listen 80 directive in the httpd.conf. However, when we add another directive Listen 9000 to httpd.conf, httpd does not respond to HTTP request sent to port 80. I just did a quick test with httpd-2.4.3 on Windows and NetWare, and both work fine with your configuration: Listen 80 Listen 9000 httpd serves both ports as it should. One thing I found though: before I did look into the manual I did just wrongly configure: Listen 80 9000 this leaded to multiple crashes (on Windows) where nothing was logged to the error log; but eventlog entries: Fehlgeschlagene Anwendung httpd.exe, Version 2.4.3.0, fehlgeschlagenes Modul libhttpd.dll, Version 2.4.3.0, Fehleradresse 0x00028628. so seems we could here do a better check for the 2nd parameter ... Gün.
Re: Powered by icon for httpd-2.4 needs update
Am 04.10.2012 05:15, schrieb Eric Covener: http://people.apache.org/~gsmith/httpd/apache_pb2copy.png http://www.humbedooh.com/apache/apache_pb.png http://www.humbedooh.com/apache/apache_pb2.png http://www.humbedooh.com/apache/apache_pb3.png pb3 has my vote yep, mine too, and is exactly what I had in mind! Gün.
Re: Powered by icon for httpd-2.4 needs update
Hi Daniel, Am 04.10.2012 15:05, schrieb Daniel Gruno: Do we need to call a vote on this, or will all the pluses, that have been flying around in the thread, suffice? There seems to be an overwhelming majority supporting the use of http://www.humbedooh.com/apache/apache_pb3.png I dont think that we need a vote; I count at least 4 committers: Eric, Rainer, Joe, and me + 2 other non-binding votes for pb3; and 1 vote from Nick for pb2; this would usually make a vote pass - so go ahead and commit the pb3 one to the 2.4.x branch, together with the refreshed ones + svg which you committed to trunk; and if you have more mood for this then would be cool if you would commit to trunk one with 2.5 as version ... - just for those living at the leading edge ... ;-) thanks also from me for your effort! Gün.
Re: Powered by icon for httpd-2.4 needs update
Am 02.10.2012 15:58, schrieb Daniel Gruno: I can do a 260x30, I hope that's close enough :) If there are no objections, I'll create the various png/gif versions and commit them to trunk later today. go ahead - thats overdue! Gün.
Re: Powered by icon for httpd-2.4 needs update
Am 03.10.2012 22:25, schrieb Guenter Knauf: Am 02.10.2012 15:58, schrieb Daniel Gruno: I can do a 260x30, I hope that's close enough :) If there are no objections, I'll create the various png/gif versions and commit them to trunk later today. go ahead - thats overdue! oh, I should read all mails before I post a reply ... :-P now would be cl if you commit new ones with '2.5' to trunk ;-) Gün.
Re: Powered by icon for httpd-2.4 needs update
Hi Daniel, Am 03.10.2012 22:25, schrieb Guenter Knauf: Am 02.10.2012 15:58, schrieb Daniel Gruno: I can do a 260x30, I hope that's close enough :) If there are no objections, I'll create the various png/gif versions and commit them to trunk later today. go ahead - thats overdue! may I ask for another one? We got some time back discussions that httpd != Apache, and in this light it would probably more correct if the logo text would read: Powered by httpd 2.4 and this then perhaps right-aligned ... can you perhaps give that a try and show here how this looks? Thanks! Gün.
