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: svn commit: r1492782 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
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. Rainer
Re: svn commit: r1492782 - /httpd/httpd/trunk/docs/manual/mod/mod_lua.xml
On Mon, Jun 17, 2013 at 12:03 PM, 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 ... > FWIW I used to hit something similar a very long time ago with the IBM JDK. The linuxppc branch in build.sh raises the stack size case "`uname -a`" in CYGWIN*) cygwin=true ;; Darwin*) darwin=true if [ -z "$JAVA_HOME" ] ; then JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home fi ;; Linux*ppc*) ANT_OPTS="$ANT_OPTS -Xss1m -ss1m" ;; esac
Re: increase socache_shmcb maximum size
On Jun 17, 2013, at 11:34 AM, Graham Leggett wrote: > On 17 Jun 2013, at 3:15 PM, Jens Låås wrote: > >> Current maximum size of socache_shmcb is 64MB, which is rather small if you >> want to use it with mod_cache_socache. >> Memory is cheap etc. >> >> I also noticed that different data types seemed to be used to represent >> cache sizes: apr_size_t and unsigned int. >> >> Attached suggestion is to base the maximum size on apr_size_t. Sets max to >> half of maximum representable by apr_size_t. > > In theory we should just limit it to APR_SIZE_T_MAX, as you say the cache > size can be large, if it fits in RAM it fits in RAM. > +1
Re: increase socache_shmcb maximum size
2013/6/17 Graham Leggett > On 17 Jun 2013, at 3:15 PM, Jens Låås wrote: > > > Current maximum size of socache_shmcb is 64MB, which is rather small if > you want to use it with mod_cache_socache. > > Memory is cheap etc. > > > > I also noticed that different data types seemed to be used to represent > cache sizes: apr_size_t and unsigned int. > > > > Attached suggestion is to base the maximum size on apr_size_t. Sets max > to half of maximum representable by apr_size_t. > > In theory we should just limit it to APR_SIZE_T_MAX, as you say the cache > size can be large, if it fits in RAM it fits in RAM. > > Undoubtably correct. Even better :-) Cheers, Jens > Regards, > Graham > -- > >
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=1492782&r1=1492781&r2=1492782&view=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 & 4 + 5'
+local unescaped = r:unescape(url) -- returns 'http://foo.bar/1 2 3 & 4 + 5'
+
+
+
+r:construct_url(string) -- Constructs an URL from an URI
+
+local url = r:construct_url(r.uri)
@@ -863,7 +869,7 @@ r:state_query(string) -- Queries the ser
-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
-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
+
+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).
+
+
+
+r:mkdir(dir [,mode]) -- Creates a directory and sets mode to optional mode
paramter.
+
+
+
+r:rmdir(dir) -- Removes a directory.
+
+
+
+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
+
+
+
+r.date_parse_rfc(string) -- Parses a date/time string and returns seconds
since epoche.
+
+
Logging Functions
Re: increase socache_shmcb maximum size
On 17 Jun 2013, at 3:15 PM, Jens Låås wrote: > Current maximum size of socache_shmcb is 64MB, which is rather small if you > want to use it with mod_cache_socache. > Memory is cheap etc. > > I also noticed that different data types seemed to be used to represent cache > sizes: apr_size_t and unsigned int. > > Attached suggestion is to base the maximum size on apr_size_t. Sets max to > half of maximum representable by apr_size_t. In theory we should just limit it to APR_SIZE_T_MAX, as you say the cache size can be large, if it fits in RAM it fits in RAM. Regards, Graham --
increase socache_shmcb maximum size
Hello! Current maximum size of socache_shmcb is 64MB, which is rather small if you want to use it with mod_cache_socache. Memory is cheap etc. I also noticed that different data types seemed to be used to represent cache sizes: apr_size_t and unsigned int. Attached suggestion is to base the maximum size on apr_size_t. Sets max to half of maximum representable by apr_size_t. Regards, Jens mod_socache_shmcb.pat Description: Binary data
Re: mod_security core dumps and r->per_dir_config
I finally came around to reinstalling but sadly it didn't help. I still get the exact same core dumps :-/ If anyone else has experienced similiar issues I would be grateful for some input. > Caveat: I am one data point, I recently had the problem, and a rebuild solved it for me. That doesn't mean the problem isn't the same for you. True but one is still better then none ;-) Cheers, Thomas On Fri, May 24, 2013 at 11:12 AM, Graham Leggett wrote: > On 24 May 2013, at 11:03 AM, Thomas Eckert > wrote: > > > How did you investigate into this ? I'll assume with "rebuild" you mean > you rebuilt apache2 from source and reinstalled it. What made you rebuild > it in this scenario ? > > Yes, in my case the module that was returning NULL for per_dir_config was > part of httpd, and a make distclean followed by make all sorted it out. > Changes to header files had been made, and I suspect this was part of my > specific problem. > > > Also, why do you think rebuilding solved it ? I'm being so specific > about investigation options since rebuilding and reinstalling it is out of > question in my case. > > In that case are you 200% sure that the headers you are using to build > against match the binaries you are building against? In the Redhat world, > headers and binaries are packaged separately, and other OSes are probably > similar. > > Caveat: I am one data point, I recently had the problem, and a rebuild > solved it for me. That doesn't mean the problem isn't the same for you. > > Regards, > Graham > -- > >
