Session.py bug?
Hi, I think I might have spotted a slight bug in Session.py. When the 'secret' parameter is supplied to use the SignedCookie class, it appears that __init__ of BaseSession doesn't check the return type of get_cookies(). If I understand the SignedCookie docs correctly, if the cookie value doesn't match its signature, it simply returns the contents as a Cookie rather than a SignedCookie (indicating that the user tampered with their cookie before sending it back). However, there is no check in BaseSession's __init__ that the return of get_cookies() is a SignedCookie in the case that 'secret' is supplied. Perhaps a minor point, but it would seem to make the option of using SignedCookies rather pointless, since the signature isn't being checked. Presumably if the cookie has been tampered with, your only safe option is to throw it away and generate a new one. I think this can be achieved by changing the lines: if cookies.has_key(session_cookie_name): self._sid = cookies[session_cookie_name].value To something like: if cookies.has_key(session_cookie_name): if not secret or type(cookes[session_cookie_name]) \ is Cookie.SignedCookie: self._sid = cookies[session_cookie_name].value I'm fairly new to mod_python, so if I'm mistaken then my apologies, and a quick explanation of why would be very much appreciated! ^_^ Thanks, - Andy
Re: How to detect the mpm used via apxs?
* Mladen Turk [EMAIL PROTECTED] wrote: Hi, Anyone knows how to detect the mpm used so that module can be build with/without threading code depending if the mpm is prefork or any other threaded one like worker by using apxs? are you shure you really want to know the mpm name instead of just a flag which tells you if threading is available ? The only way I can imagine is to parse the stdout from httpd, but IMHO something like apxs -q MPM should do the trick like it does for CFLAGS or INCLUDES. Actually, I don't like the whole apxs script at all. Why not just install an extra .pc file for each installed module, also for the MPM's ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: How to detect the mpm used via apxs?
* Guy Hulbert [EMAIL PROTECTED] wrote: snip or if you've already compiled it ... $ /usr/sbin/apache2 -V | grep MPM -D APACHE_MPM_DIR=server/mpm/worker Bad, very bad. Breaks crosscompiling. Ah, yeah, apache cannot be crosscompile'd w/o massive manual intervention at all ... ;-o (but I'm working on that ...) cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
[jira] Commented: (MODPYTHON-187) Hang on subscripted access to request.subprocess_env.
[
http://issues.apache.org/jira/browse/MODPYTHON-187?page=comments#action_12431530
]
Jim Gallacher commented on MODPYTHON-187:
-
I've audited tableobject.c for other lines where NULL is being passed to
PyString_FromString and found a few functions that may segfault if they are
called in the post read request phase where SCRIPT_FILENAME is NULL.
Line numbers are for version 3.3.0-dev-20060827, r437300.
line 178 in table_repr()
PyString_ConcatAndDel(s, PyString_FromString(elts[i].val));
line 366 in function table_values()
PyObject *val = PyString_FromString(elts[i].val);
line 792 in function table_traverse()
PyObject *v = PyString_FromString(elts[i].val);
line 845 in function select_value()
return PyString_FromString(elts-val);
We should audit all our code to make sure we are not making the same mistake
with PyString_FromString elsewhere.
Hang on subscripted access to request.subprocess_env.
-
Key: MODPYTHON-187
URL: http://issues.apache.org/jira/browse/MODPYTHON-187
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.10
Environment: Apache: 2.0.59
ModPython: 3.2.10
Python: 2.4
OS: Windows Server 2003
Reporter: Alan Kennedy
Attachments: MP187-2006-08-28-jgallacher-1.diff
When subscripted access is used to access variable 'SCRIPT_FILENAME' in the
request.subprocess_env table/mapping, the code hangs.
The following snippet illustrates the problem.
# -=-=-=-=-=-=
def postreadrequesthandler(request):
request.add_common_vars()
value = request.subprocess_env['SCRIPT_FILENAME']# This hangs
# value = request.subprocess_env.get('SCRIPT_FILENAME')# This works
return apache.OK
# -=-=-=-=-=-=
The strange thing is that the .get() access works fine: only the subscript
hangs?
If anyone is wondering about a use-case, I don't actually have one. I was
just iterating over the contents of the request.subprocess_env using a for
loop (code below), and found that the code hung when accessing
'SCRIPT_FILENAME', and not for any other variable.
# -=-=-=
request.add_common_vars()
d = {}
for sek in request.subprocess_env.keys():
d[sek] = request.subprocess_env[sek]
# -=-=-=
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Announce] apache httpd listed in CSDB (comprehensive source database)
Hi folks, I'd like to accounce that the apache httpd, apr + friends are listed in the Comprehensive Source Database at: http://sourcefarm.metux.de This database contains the tarball URLs of dozens of package releases and it's intended to be used by fully automated systems, so no more manual downloading or URLs maintenance is necessary. You can help us greatly, if you regularily check the database records or even join our team and contribute crawlers. Current package records for the apache httpd: http://sourcefarm.metux.de/webfront/?show=packagepackage=apache-apr http://sourcefarm.metux.de/webfront/?show=packagepackage=apache-apr-util http://sourcefarm.metux.de/webfront/?show=packagepackage=apache-iconv http://sourcefarm.metux.de/webfront/?show=packagepackage=apache-httpd2 Greets, -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: perchild
* Guy Hulbert [EMAIL PROTECTED] wrote: Hi, I'm looking at perchild with the aim of getting it working. maybe you're looking for: http://www.metux.de/mpm The project has been stalled for quite a while :( But maybe it's time for revival ? In STATUS I see: Get perchild to work on platforms other than Linux. This will require a portable mechanism to pass data and file/socket descriptors between vhost child groups. Perchild *never* worked. The idea isn't bad - we took much of it into metuxmpm, but there were major design problems. For example: each childs can accept clients. That's very bad, because it allows some user to intercept another's requests with some probability. The whole idea of passing *sockets* (instead of requests) between processes only works on very few systems, ie. Linux, BSD and perhaps some others. So the whole portability issue is useless - those MPMs only work some Unix'es, and there evrythere the same. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: perchild
On Wed, Aug 30, 2006 at 12:59:02PM +0200, Enrico Weigelt wrote: The whole idea of passing *sockets* (instead of requests) between processes only works on very few systems, ie. Linux, BSD and perhaps some others. So the whole portability issue is useless - those MPMs only work some Unix'es, and there evrythere the same. None of our MPMs offers that kind of portability. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[PATCH] split ap_get_server_version() into two functions...
... so that ServerTokens doesn't affect what gets logged to the error
log at startup (or any other place where we want the description of
the server instead of the banner to be written over the network).
This patch axes ap_get_server_version() so that third-party modules
will be forced to make a choice in post-2.2.x versions -- call
ap_get_server_banner() to retrieve the string suitable for sending
over the network (as controlled by ServerTokens) or call
ap_get_server_description() to retrieve the string that describes the
server version and certain plug-in modules.
I haven't actually changed the returned strings with this patch, but
instead would like to see any comments on the direction. The two
functions are present and all httpd code has been modified to call the
proper function, which is also subject to a useful review. What about
status pages? Is the server version and module configuration somehow
more private than the status page itself, such that they should use
ap_get_server_banner() as in the current patch?
Index: server/mpm/winnt/service.c
===
--- server/mpm/winnt/service.c (revision 438471)
+++ server/mpm/winnt/service.c (working copy)
@@ -436,7 +436,7 @@
/* Time to fix up the description, upon each successful restart
*/
-full_description = ap_get_server_version();
+full_description = ap_get_server_description();
if ((osver.dwPlatformId == VER_PLATFORM_WIN32_NT)
(osver.dwMajorVersion 4)
Index: server/mpm/winnt/mpm_winnt.c
===
--- server/mpm/winnt/mpm_winnt.c(revision 438471)
+++ server/mpm/winnt/mpm_winnt.c(working copy)
@@ -1705,7 +1705,7 @@
/* A real-honest to goodness parent */
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s configured -- resuming normal operations,
- ap_get_server_version());
+ ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
Server built: %s, ap_get_server_built());
Index: server/mpm/mpmt_os2/mpmt_os2.c
===
--- server/mpm/mpmt_os2/mpmt_os2.c (revision 438471)
+++ server/mpm/mpmt_os2/mpmt_os2.c (working copy)
@@ -207,7 +207,7 @@
int listener_num, num_listeners, slot;
ULONG rc;
-printf(%s \n, ap_get_server_version());
+printf(%s \n, ap_get_server_description());
set_signals();
if (ap_setup_listeners(ap_server_conf) 1) {
@@ -270,7 +270,7 @@
ap_scoreboard_image-global-restart_time = apr_time_now();
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s configured -- resuming normal operations,
-ap_get_server_version());
+ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_INFO, 0, ap_server_conf,
Server built: %s, ap_get_server_built());
#ifdef AP_MPM_WANT_SET_ACCEPT_LOCK_MECH
Index: server/mpm/netware/mpm_netware.c
===
--- server/mpm/netware/mpm_netware.c(revision 438471)
+++ server/mpm/netware/mpm_netware.c(working copy)
@@ -723,7 +723,7 @@
request_count = 0;
ClearScreen (getscreenhandle());
-printf(%s \n, ap_get_server_version());
+printf(%s \n, ap_get_server_description());
for (i=0;iSERVER_NUM_STATUS;i++) {
status_array[i] = 0;
@@ -793,7 +793,7 @@
ap_listen_rec *lr;
module **m;
-printf(%s\n, ap_get_server_version());
+printf(%s\n, ap_get_server_description());
if (ap_my_addrspace (ap_my_addrspace[0] != 'O') (ap_my_addrspace[1]
!= 'S'))
printf( Running in address space %s\n, ap_my_addrspace);
@@ -899,7 +899,7 @@
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s configured -- resuming normal operations,
-ap_get_server_version());
+ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_INFO, 0, ap_server_conf,
Server built: %s, ap_get_server_built());
#ifdef AP_MPM_WANT_SET_ACCEPT_LOCK_MECH
@@ -1204,7 +1204,7 @@
restart();
}
else if (!strnicmp(VERSION,szcommandLine[iCommandLen],3)) {
-printf(Server version: %s\n, ap_get_server_version());
+printf(Server version: %s\n, ap_get_server_description());
printf(Server built: %s\n, ap_get_server_built());
}
else if (!strnicmp(MODULES,szcommandLine[iCommandLen],3)) {
Index: server/mpm/beos/beos.c
===
--- server/mpm/beos/beos.c (revision 438471)
+++ server/mpm/beos/beos.c (working copy)
@@ -935,7 +935,7 @@
*/
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s
porstfs bug t2000 and 2.2
We tested a Sun t2000 with httpd 2.2. It did okay. Now, Sun says there is an issue with 2.2 and portfs on Solaris 10 on the t2000. Not real sure what this means. Anyone else heard this? -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: porstfs bug t2000 and 2.2
On Wed, Aug 30, 2006 at 09:20:52AM -0400, Brian Akins wrote: We tested a Sun t2000 with httpd 2.2. It did okay. Now, Sun says there is an issue with 2.2 and portfs on Solaris 10 on the t2000. It didn't do very well for me with Solaris 10 either. Not real sure what this means. Anyone else heard this? Yep, it's event ports, which we support. How their implementation handles it, who knows :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: porstfs bug t2000 and 2.2
Look at Sun Alert 102485: http://sunsolve.sun.com/search/document.do?assetkey=1-26-102485-1 The bug should have been fixed with 118833-12 several months ago. Most early evaluaters of Niagara with Apache 2.2 ran into kernel panics because of the bug. The most recent kernel update patch is 118833-20 (SPARC versions, X86 should be analogous). Regards, Rainer Colm MacCarthaigh schrieb: On Wed, Aug 30, 2006 at 09:20:52AM -0400, Brian Akins wrote: We tested a Sun t2000 with httpd 2.2. It did okay. Now, Sun says there is an issue with 2.2 and portfs on Solaris 10 on the t2000. It didn't do very well for me with Solaris 10 either. Not real sure what this means. Anyone else heard this? Yep, it's event ports, which we support. How their implementation handles it, who knows :-)
mod_slotmem
With all the talk of a generic scoreboard, here's something I whipped
up that allows any other module to have some amount of memory per
worker slot. We have a different module in-house at CNN which does
something similar. This one is a little rough around the edges, but
gives an idea of what I was thinking about doing.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
#ifndef __MOD_slotmem__
#define __MOD_slotmem__
typedef struct ap_slotmem_t ap_slotmem_t;
typedef apr_status_t ap_slotmem_callback_fn_t(void* mem, void *data, apr_pool_t
*pool);
AP_DECLARE(apr_status_t)ap_slotmem_do(ap_slotmem_t *s, ap_slotmem_callback_fn_t
*func, void *data, apr_pool_t *pool);
AP_DECLARE(apr_status_t) ap_slotmem_create(ap_slotmem_t **new, const char
*name, apr_size_t item_size, apr_pool_t *pool);
AP_DECLARE(apr_status_t) ap_slotmem_mem(ap_slotmem_t *s, conn_rec *c,
void**mem);
#endif
#include httpd.h
#include http_config.h
#include http_protocol.h
#include http_connection.h
#include ap_config.h
#include http_log.h
#include scoreboard.h
#include apr_strings.h
#include apr_shm.h
#include ap_mpm.h
#include sys/types.h
#include unistd.h
#include mod_status.h
#include mod_slotmem.h
module AP_MODULE_DECLARE_DATA slotmem_module;
static int server_limit = 0;
static int thread_limit = 0;
static int total_limit = 0;
static apr_array_header_t *slotmem_array = NULL;
struct ap_slotmem_t {
apr_pool_t *pool;
const char *name;
apr_shm_t *shm;
void *mem;
apr_size_t item_size; /*size of each item*/
apr_size_t total_size;
};
AP_DECLARE(apr_status_t)ap_slotmem_do(ap_slotmem_t *s, ap_slotmem_callback_fn_t
*func, void *data, apr_pool_t *pool) {
apr_status_t rv = APR_SUCCESS;
int i;
void *mem;
for(i = 0; i total_limit; i++) {
mem = s-mem + (i * s-item_size);
if((rv = func(mem, data, pool)) != APR_SUCCESS) {
return rv;
}
}
return rv;
}
AP_DECLARE(apr_status_t) ap_slotmem_create(ap_slotmem_t **n, const char *name,
apr_size_t item_size, apr_pool_t *pool) {
ap_slotmem_t *s, **new;
s = apr_pcalloc(pool, sizeof(ap_slotmem_t));
s-pool = pool;
s-name = apr_pstrdup(pool, name);
s-item_size = item_size;
new = (ap_slotmem_t **) apr_array_push(slotmem_array);
(*new) = (ap_slotmem_t *) s;
*n = s;
return APR_SUCCESS;
}
AP_DECLARE(apr_status_t) ap_slotmem_mem(ap_slotmem_t *s, conn_rec *c, void
**mem) {
/*this should work for all mpm's*/
void *d = s-mem + (c-id * s-item_size);
*mem = d;
if(!d) {
ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c,
ap_slotmem_mem: d is NULL, %ld, %p,
c-id, s-mem
);
return APR_EGENERAL;
}
return APR_SUCCESS;
}
static int slotmem_status(request_rec *r, int flags)
{
int i;
ap_slotmem_t *sb, **list;
if (!(flags AP_STATUS_SHORT)) {
ap_rputs(hr /bslotmems/b\n, r);
ap_rputs(table border=1trtdbName/b/tdtdbItem
Size/b/tdtdbTotal Size/b/td/tr\n, r);
}
list = (ap_slotmem_t **)slotmem_array-elts;
for(i = 0; i slotmem_array-nelts; i++) {
sb = list[i];
if (!(flags AP_STATUS_SHORT)) {
ap_rprintf(r,
trtd%s/tdtd%APR_SIZE_T_FMT/tdtd%APR_SIZE_T_FMT/td/tr\n,
sb-name, sb-item_size, sb-total_size);
} else {
ap_rprintf(r, slotmem: %s %APR_SIZE_T_FMT%APR_SIZE_T_FMT\n,
sb-name, sb-item_size, sb-total_size);
}
}
if (!(flags AP_STATUS_SHORT)) {
ap_rputs(/table\n, r);
}
return OK;
}
static int post_config(apr_pool_t *p, apr_pool_t * plog, apr_pool_t * ptemp,
server_rec *s)
{
apr_size_t amt;
apr_time_t now;
pid_t pid;
char *file;
ap_slotmem_t *sb, **list;
int i;
apr_status_t rv;
const char *temp_dir;
char *data = NULL;
/*have we been here before? */
apr_pool_userdata_get((void *) data, __FILE__,
s-process-pool);
if (!data) {
apr_pool_userdata_set((const void *) 1, __FILE__,
apr_pool_cleanup_null, s-process-pool);
return OK;
}
ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, thread_limit);
ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, server_limit);
total_limit = thread_limit * server_limit;
now = apr_time_now();
pid = getpid();
if ((rv = apr_temp_dir_get(temp_dir, p)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, s,
apr_temp_dir_get failed);
return rv;
}
/*XXX: currently, this uses one shm per slotmem. We could try to pack them
all into a few larger shm's*/
list = (ap_slotmem_t **)slotmem_array-elts;
for(i = 0; i slotmem_array-nelts; i++) {
sb = list[i];
sb-total_size = amt = sb-item_size *
Re: mod_slotmem
On Wed, 2006-08-30 at 10:37 -0400, Brian Akins wrote:
With all the talk of a generic scoreboard, here's something I whipped
up that allows any other module to have some amount of memory per
worker slot. We have a different module in-house at CNN which does
something similar. This one is a little rough around the edges, but
gives an idea of what I was thinking about doing.
Nice stuff but I am not sure that having shared memory per slot scales
when having a lot of entries, but that makes sure that one
process/thread won't overwrite another one slot.
I will try to use memory providers of httpd-scoreboard to provide the
memory to your module.
Cheers
Jean-Frederic
plain text document attachment (mod_slotmem.h)
#ifndef __MOD_slotmem__
#define __MOD_slotmem__
typedef struct ap_slotmem_t ap_slotmem_t;
typedef apr_status_t ap_slotmem_callback_fn_t(void* mem, void *data,
apr_pool_t *pool);
AP_DECLARE(apr_status_t)ap_slotmem_do(ap_slotmem_t *s,
ap_slotmem_callback_fn_t *func, void *data, apr_pool_t *pool);
AP_DECLARE(apr_status_t) ap_slotmem_create(ap_slotmem_t **new, const char
*name, apr_size_t item_size, apr_pool_t *pool);
AP_DECLARE(apr_status_t) ap_slotmem_mem(ap_slotmem_t *s, conn_rec *c,
void**mem);
#endif
plain text document attachment (mod_slotmem.c)
#include httpd.h
#include http_config.h
#include http_protocol.h
#include http_connection.h
#include ap_config.h
#include http_log.h
#include scoreboard.h
#include apr_strings.h
#include apr_shm.h
#include ap_mpm.h
#include sys/types.h
#include unistd.h
#include mod_status.h
#include mod_slotmem.h
module AP_MODULE_DECLARE_DATA slotmem_module;
static int server_limit = 0;
static int thread_limit = 0;
static int total_limit = 0;
static apr_array_header_t *slotmem_array = NULL;
struct ap_slotmem_t {
apr_pool_t *pool;
const char *name;
apr_shm_t *shm;
void *mem;
apr_size_t item_size; /*size of each item*/
apr_size_t total_size;
};
AP_DECLARE(apr_status_t)ap_slotmem_do(ap_slotmem_t *s,
ap_slotmem_callback_fn_t *func, void *data, apr_pool_t *pool) {
apr_status_t rv = APR_SUCCESS;
int i;
void *mem;
for(i = 0; i total_limit; i++) {
mem = s-mem + (i * s-item_size);
if((rv = func(mem, data, pool)) != APR_SUCCESS) {
return rv;
}
}
return rv;
}
AP_DECLARE(apr_status_t) ap_slotmem_create(ap_slotmem_t **n, const char
*name, apr_size_t item_size, apr_pool_t *pool) {
ap_slotmem_t *s, **new;
s = apr_pcalloc(pool, sizeof(ap_slotmem_t));
s-pool = pool;
s-name = apr_pstrdup(pool, name);
s-item_size = item_size;
new = (ap_slotmem_t **) apr_array_push(slotmem_array);
(*new) = (ap_slotmem_t *) s;
*n = s;
return APR_SUCCESS;
}
AP_DECLARE(apr_status_t) ap_slotmem_mem(ap_slotmem_t *s, conn_rec *c, void
**mem) {
/*this should work for all mpm's*/
void *d = s-mem + (c-id * s-item_size);
*mem = d;
if(!d) {
ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c,
ap_slotmem_mem: d is NULL, %ld, %p,
c-id, s-mem
);
return APR_EGENERAL;
}
return APR_SUCCESS;
}
static int slotmem_status(request_rec *r, int flags)
{
int i;
ap_slotmem_t *sb, **list;
if (!(flags AP_STATUS_SHORT)) {
ap_rputs(hr /bslotmems/b\n, r);
ap_rputs(table border=1trtdbName/b/tdtdbItem
Size/b/tdtdbTotal Size/b/td/tr\n, r);
}
list = (ap_slotmem_t **)slotmem_array-elts;
for(i = 0; i slotmem_array-nelts; i++) {
sb = list[i];
if (!(flags AP_STATUS_SHORT)) {
ap_rprintf(r,
trtd%s/tdtd%APR_SIZE_T_FMT/tdtd%APR_SIZE_T_FMT/td/tr\n,
sb-name, sb-item_size, sb-total_size);
} else {
ap_rprintf(r, slotmem: %s %APR_SIZE_T_FMT%APR_SIZE_T_FMT\n,
sb-name, sb-item_size, sb-total_size);
}
}
if (!(flags AP_STATUS_SHORT)) {
ap_rputs(/table\n, r);
}
return OK;
}
static int post_config(apr_pool_t *p, apr_pool_t * plog, apr_pool_t * ptemp,
server_rec *s)
{
apr_size_t amt;
apr_time_t now;
pid_t pid;
char *file;
ap_slotmem_t *sb, **list;
int i;
apr_status_t rv;
const char *temp_dir;
char *data = NULL;
/*have we been here before? */
apr_pool_userdata_get((void *) data, __FILE__,
s-process-pool);
if (!data) {
apr_pool_userdata_set((const void *) 1, __FILE__,
apr_pool_cleanup_null, s-process-pool);
return OK;
}
ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, thread_limit);
ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, server_limit);
total_limit = thread_limit *
Re: mod_slotmem
Jean-frederic Clere wrote: Nice stuff but I am not sure that having shared memory per slot scales when having a lot of entries, but that makes sure that one process/thread won't overwrite another one slot. It scales very nicely. We run with max clients set between 16k-32k with no issues. Our item sizes range from 64-264 bytes. at 264 bytes and 24k max clients, it requires about 6.5 MB of shared memory and we usually have 8-12 slotmems of varying sizes, so we use about 32-64 MB of shared memory for all the slotmems. It is very fast as there is no locking necessary as each slot is only every written to by a single writer (it's tied to a connection id). -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: porstfs bug t2000 and 2.2
On 8/30/06, Rainer Jung [EMAIL PROTECTED] wrote: The most recent kernel update patch is 118833-20 (SPARC versions, X86 should be analogous). Yah, that bug has been fixed. (Paul reported the bug early on, I think.) We have also heard reports that the SSL crypto engine on the T2000's is horked. We've been told that upcoming firmware should resolve that issue. FWIW, we're going to be deploying httpd on one of the ASF's T2000 soon (it's going to eventually take over for our Itanium box). So, if it's unstable, we'll be finding out real soon now. -- justin
Re: mod_slotmem
Brian Akins wrote: Jean-frederic Clere wrote: Nice stuff but I am not sure that having shared memory per slot scales when having a lot of entries, but that makes sure that one process/thread won't overwrite another one slot. It scales very nicely. We run with max clients set between 16k-32k with no issues. Our item sizes range from 64-264 bytes. at 264 bytes and 24k max clients, it requires about 6.5 MB of shared memory and we usually have 8-12 slotmems of varying sizes, so we use about 32-64 MB of shared memory for all the slotmems. That is no nicely, that is greatly ;-) Cheers Jean-Frederic It is very fast as there is no locking necessary as each slot is only every written to by a single writer (it's tied to a connection id).
Re: porstfs bug t2000 and 2.2
Yes - there are issues with Apache on Solaris 10 when using SSL (nothing to do with the T2000). We currently have two bugs outstanding : http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6375348 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6374503 In our testing, this causes about a 10-12% performance degradation, but is not specific to Apache 2.2.If you run apache as root, there is no degradation at all and should see improved performance with the T2000 crypto hardware. As you correctly point out, the event port bug has been fixed so make sure that your T2000 box has this patch. We have just released 'Cool Stack' - optimized versions of apache and other common OSS apps for SPARC (x86 coming soon). Please see http://cooltools.sunsource.net/coolstack to download. Shanti PAE, Sun Microsystems Justin Erenkrantz wrote: On 8/30/06, Rainer Jung [EMAIL PROTECTED] wrote: The most recent kernel update patch is 118833-20 (SPARC versions, X86 should be analogous). Yah, that bug has been fixed. (Paul reported the bug early on, I think.) We have also heard reports that the SSL crypto engine on the T2000's is horked. We've been told that upcoming firmware should resolve that issue. FWIW, we're going to be deploying httpd on one of the ASF's T2000 soon (it's going to eventually take over for our Itanium box). So, if it's unstable, we'll be finding out real soon now. -- justin
Re: perchild
On Wed, 2006-30-08 at 23:02 +0200, Enrico Weigelt wrote: * Guy Hulbert [EMAIL PROTECTED] wrote: On Wed, 2006-30-08 at 12:59 +0200, Enrico Weigelt wrote: * Guy Hulbert [EMAIL PROTECTED] wrote: Hi, I'm looking at perchild with the aim of getting it working. maybe you're looking for: http://www.metux.de/mpm I found that. The links don't work. ah, bug in the php script (was too old for my server - still relied on register_globals ;-o) snip Ok. I have the patch against 2.0.48 ... I will see what I can do with it. --gh
[STATUS] (httpd-2.0) Wed Aug 30 23:49:53 2006
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2006-07-27 13:26:10 -0400 (Thu, 27 Jul 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.60 : in maintenance 2.0.59 : tagged July 27, 2006 2.0.58 : released May 1, 2006 as GA. 2.0.57 : tagged April 19, 2006, not released. 2.0.56 : tagged April 16, 2006, not released. 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] *) Reverse Proxy fixes: Location bug and Cookie support Patch is at http://people.apache.org/~colm/httpd-2.0-reverse-proxy-cookie.patch and is in production with Clients. +1: niq, wrowe wrowe adds; looks good, no way to apply this without a minor bump *) Backport 102870; PR 17217; stop linking OpenSSL .so's to support/* binaries
[STATUS] (httpd-trunk) Wed Aug 30 23:48:30 2006
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* If the parent process dies, should the remaining child processes
gracefully self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
hot spare).
See: Message-ID: [EMAIL PROTECTED]
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
+1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for 2.2?
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr-main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see MUST v.s. SHOULD v.s. MAY
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at
