keepalive connection broken
Hi,
I have researched a problem with broken keepalive connections which is
similar to bug# 41109. And I have found that in worker.c function
'int ap_graceful_stop_signalled(void)' returns listener_may_exit.
Basically all the code is like this:
int ap_graceful_stop_signalled(void)
/**/
{
/* note: for a graceful termination, listener_may_exit will be set
before
* workers_may_exit, so check listener_may_exit
*/
return listener_may_exit;
}
And it causes keepalive connection to terminate abruptly if server
process exceeds MaxRequestsPerChild.
In prefork.c for instance this function is different and states for:
int ap_graceful_stop_signalled(void)
{
/* not ever called anymore... */
return 0;
}
As far as it is called only from 'static int
ap_process_http_connection(conn_rec *c)'
'if (ap_graceful_stop_signalled())
break;' out of serving loop,
I believe 'ap_graceful_stop_signalled' to 'return 0' will solve the problem.
Have tried with trunk and 2.2.x branch with the same positive result.
Patch for trunk is attached.
--
Best regards,
Dmytro
Index: server/mpm/worker/worker.c
===
--- server/mpm/worker/worker.c (revision 545597)
+++ server/mpm/worker/worker.c (working copy)
@@ -513,14 +513,9 @@
*/
int ap_graceful_stop_signalled(void)
-/* XXX this is really a bad confusing obsolete name
- * maybe it should be ap_mpm_process_exiting?
- */
{
-/* note: for a graceful termination, listener_may_exit will be set before
- * workers_may_exit, so check listener_may_exit
- */
-return listener_may_exit;
+/* not ever called anymore... */
+return 0;
}
/*
Re: keepalive connection broken
Lieber Kunde, vielen Dank fuer Ihre Anfrage. Diese wurde weitergeleitet und wird schnellstmoeglich bearbeitet. Fuer alle zukuenftigen Fragen zu ihrer Registrierung, Ihrem Native Instruments Account oder bei Problemen mit Ihrer Aktivierung, bieten wir Ihnen ein komfortables Online-Formular an: http://www.native-instruments.com/index.php?id=regsuppfrm_de Mit der Verwendung des Formulars helfen Sie uns dabei, Ihre Anfragen noch schneller und effizienter zu beantworten. Vielen Dank! Mit freundlichen Gruessen, Ihr NATIVE INSTRUMENTS Registrierungs Team Dear Customer, Many thanks for your inquiry. Your message has been passed on to our Registration Team and will be dealt with shortly. For all future requests regarding the Registration, your Native Instruments account, or problems with the activation, we offer you a simple online form at: http://www.native-instruments.com/index.php?id=regsuppfrm_us The use of the form helps to answer your queries faster and more efficiently. Many thanks and best regards, Your NATIVE INSTRUMENTS Registration Team Email contact: http://www.native-instruments.com/index.php?id=regsuppfrm_us Phone +49-30-61 10 35-14 01 Fax +49-30-61 10 35-24 00 NATIVE INSTRUMENTS GmbH Schlesische Str. 28 10997 Berlin, Germany http://www.native-instruments.com - NATIVE INSTRUMENTS - The Future of Sound - Registergericht: Amtsgericht Charlottenburg Registernummer: HRB 72458, UST.-ID.-Nr. DE 20 374 7747 Vertretungsberechtigte Geschtsfuehrer: Daniel Haver, Stephan Schmitt
RE: httpd attempts to open file.html/.htaccess (is this a bug?)
When processing a GET /.../file.html, Apache httpd briefly treats
file.html as a directory and attempts to open
docroot/.../file.html/.htaccess. The os returns ENOTDIR,
and then
processing of the request continues.
Yes, this is a somewhat known issue. Previously it caused
issues with earlier versions of reiserfs4:
http://issues.apache.org/bugzilla/show_bug.cgi?id=31126
Rici explains more details here:
http://marc.info/?l=apache-httpd-devm=109470495819687w=4
Hello Paul and Dev List,
Thanks for the reply. I checked out the links and did some code tracing
with the debugger. As one of the links pointed out, the problem is in the
block of code attached below from ap_directory_walk() in server/request.c
This block of code is contained in the directory walk that looks for sym
links and .htaccess files. It is executed immediately after appending the
next path segment, which is either a subdirectory or the file name.
The if test at the top of the block attempts to optimize by skipping the
statements the follow it. The comment on the if test states:
* If...we knew r-filename was a file, and
* if...we have strict (case-sensitive) filenames, or
* we know the canonical_filename matches to _this_ name, and
* if...we have allowed symlinks
* skip the lstat and dummy up an APR_DIR value for thisinfo.
The first problem with the if test is that it doesn't recognize when the
segment is actually the file name itself, and therefore the type is APR_REG
rather than APR_DIR. This could easily be fixed, but there may be a few
other problems.
First, it should be mentioned that the optimization can be removed and then
httpd will behave correctly: it will not do a spurious access on
file.html/.htaccess. However, when the optimization is removed, it will
then do a stat on each component in the file path, when it might not need
to.
Let's first look at the lines of code that follows the if optimization and
look at the conditions under which they are not necessary. Before starting
though, let's note that prior to beginning the directory walk,
ap_directory_walk() does a stat on the full file name, using the
APR_FINFO_MIN parameter.
Later, without optimization, it would then do a stat on each component in
the path, as follows:
1. Do a stat on the path component, looking at the link info
(APR_FINFO_LINK) rather than the target info.
2. Test if stat returned an error. Note that since the initial stat on the
full path did not return an error, the stat on the component will never
return as error (assuming the program logic is correct). This can therefore
always be optimized out.
3. Fix up the path name if the actual component name info does not match. A
mismatch is only possible with a file system that is not case sensitive, and
therefore can be optimized out if either (a) the file system is case
sensitive or (b) we already know they match; or (c) we don't care if they
match or not.
4. If the path is a link, run resolve_symlink(). This function will always
return success when OPT_SYM_LINKS (FollowSymLinks) is enabled.
5. If the path points at anything other than a directory, end processing.
So basically, these processing steps can be skipped whenever (1)
FollowSymLinks is enabled AND (2) the file system is case sensitive.
It seems to me that the optimization should actually read:
If (filesystem is case sensitive AND OPT_SYM_LINKS is enabled AND we did a
successful stat on the full file path) Then:
{ If (the path to test is the fill path AND full path points at a
regular file) Then: end processing
Else: assume path to test is a dir and skip the stat
}
These are the two things I'm concerned about:
1. In the current optimization, the comment says:
* if...we have strict (case-sensitive) filenames, or
* we know the canonical_filename matches to _this_ name, and
while the actual code says:
#ifdef CASE_BLIND_FILESYSTEM
(filename_len = canonical_len)
#endif
At first examination, it looks the comment describes the correct
implementation, but how does the test for filename_len = canonical_len
ensure that canonical_filename matches to _this_ name. Can anyone verify
this is correct?
2. When OPT_SYM_LINKS is enabled, resolve_symlink() does not test
OPT_SYM_OWNER, i.e., OPT_SYM_LINKS overrides OPT_SYM_OWNER. The
optimization however insists that OPT_SYM_LINKS is set while OPT_SYM_OWNER
is unset.
Which of these two are correct? Should resolve_symlink() always check
OPT_SYM_OWNER, even if OPT_SYM_LINKS is enabled, or should the optimization
only check OPT_SYM_LINKS?
Thanks,
Allen
-
THE PROBLEMATIC BLOCK OF CODE
/* First optimization;
* If...we knew r-filename was a file, and
* if...we have strict (case-sensitive) filenames, or
* we know the canonical_filename matches to _this_ name,
and
* if...we have allowed symlinks
* skip the lstat and dummy
Re: svn commit: r546328 - in /httpd/httpd/trunk: CHANGES include/httpd.h modules/http/http_core.c modules/ssl/ssl_engine_io.c server/core.c server/mpm/experimental/event/event.c
On 06/12/2007 02:32 AM, [EMAIL PROTECTED] wrote:
Author: pquerna
Date: Mon Jun 11 17:32:24 2007
New Revision: 546328
URL: http://svn.apache.org/viewvc?view=revrev=546328
Log:
Add a clogging_input_filters variable to the conn_rec, enabling the Event MPM
to know when its running with an input filter that buffers its own data, like
mod_ssl.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/include/httpd.h
httpd/httpd/trunk/modules/http/http_core.c
httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
httpd/httpd/trunk/server/core.c
httpd/httpd/trunk/server/mpm/experimental/event/event.c
Modified: httpd/httpd/trunk/include/httpd.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?view=diffrev=546328r1=546327r2=546328
==
--- httpd/httpd/trunk/include/httpd.h (original)
+++ httpd/httpd/trunk/include/httpd.h Mon Jun 11 17:32:24 2007
@@ -1081,6 +1081,11 @@
int data_in_input_filters;
/** Is there data pending in the output filters? */
int data_in_output_filters;
+
Nitpicking and style police: Empty lines should be completely empty and should
not contain spaces.
+/** Are there any filters that clogg/buffer the input stream, breaking
+ * the event mpm.
+ */
+int clogging_input_filters;
};
I am missing a minor bump since this is a change of the public API.
/**
Modified: httpd/httpd/trunk/modules/http/http_core.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_core.c?view=diffrev=546328r1=546327r2=546328
==
--- httpd/httpd/trunk/modules/http/http_core.c (original)
+++ httpd/httpd/trunk/modules/http/http_core.c Mon Jun 11 17:32:24 2007
@@ -119,11 +119,17 @@
return DEFAULT_HTTP_PORT;
}
+static int ap_process_http_connection(conn_rec *c);
+
Nitpicking and style: I think you should either declare a prototype at the top
of the file just before all
function implementations start or you can just move ap_process_http_connection
here (which of course
may make backports of other future changes to this file harder and thus might
not be the best solution).
static int ap_process_http_async_connection(conn_rec *c)
{
request_rec *r;
conn_state_t *cs = c-cs;
+if (c-clogging_input_filters) {
+return ap_process_http_connection(c);
+}
+
Nitpicking and style police: Empty lines should be completely empty and should
not contain spaces.
AP_DEBUG_ASSERT(cs-state == CONN_STATE_READ_REQUEST_LINE);
while (cs-state == CONN_STATE_READ_REQUEST_LINE) {
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?view=diffrev=546328r1=546327r2=546328
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_io.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_io.c Mon Jun 11 17:32:24 2007
@@ -1665,6 +1665,9 @@
filter_ctx-pbioWrite = BIO_new(bio_filter_out_method);
filter_ctx-pbioWrite-ptr = (void *)bio_filter_out_ctx_new(filter_ctx,
c);
+/* We insert a clogging input filter. Let the core know. */
+c-clogging_input_filters = 1;
+
Nitpicking and style police: Empty lines should be completely empty and should
not contain spaces.
ssl_io_input_add_filter(filter_ctx, c, ssl);
SSL_set_bio(ssl, filter_ctx-pbioRead, filter_ctx-pbioWrite);
Modified: httpd/httpd/trunk/server/mpm/experimental/event/event.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/experimental/event/event.c?view=diffrev=546328r1=546327r2=546328
==
--- httpd/httpd/trunk/server/mpm/experimental/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/experimental/event/event.c Mon Jun 11
17:32:24 2007
@@ -620,6 +620,16 @@
pt = cs-pfd.client_data;
}
+if (c-clogging_input_filters !c-aborted) {
+/* Since we have an input filter which 'cloggs' the input stream,
+ * like mod_ssl, lets just do the normal read from input filters,
+ * like the Worker MPM does.
+ */
+ap_run_process_connection(c);
+ap_lingering_close(c);
+return 0;
I am not that deep into the event MPM code, but if we get into the lingering
close state of an async connection
(c-clogging_input_filters = 0 cs-state == CONN_STATE_LINGER) we do the
following:
ap_lingering_close(c);
apr_pool_clear(p);
ap_push_pool(worker_queue_info, p);
return 1;
I fear that we will leak pools and memory if we don't clear them and push them
back in the queue.
To be honest I have no idea why we do a return 1 in this situtaion. It seems
Re: Apache2 mod_ssl with HSM support
On May 29, 2007, at 11:36 PM, Apache Devel wrote: I'd like to start a discussion about Hardware Security Module (HSM) support for mod_ssl. You may know that OpenSSL supports different HW engines. There is also support for PKCS#11 devices, a standard for communication with crypto devices - e.g. HSMs or Smartcards. Some HSM vendors support mod_ssl and their HSM with a modified OpenSSL/mod_ssl version. But support is limited to 1.3.X versions of Apache as far as we know. That's not entirely correct. Apache 2.0.x has experimental support for hardware crypto engines, and in Apache 2.2 that support is no longer experimental. I agree though that Apache tends to think of certificates and keys very much as PEM files on disk and not really anything else, which stands in the way of working with HSMs in general. Even with that limitation, HSM support works with Apache for instance with nCipher's nShield and netHSM products (Disclosure: I work for nCipher). There seems to be no standard interface for mod_ssl with HSM support for private key protection and operations. We decided to extend mod_ssl for usage with an HSM. We have a first prototype (prealpha) with limited functionality now. That sounds interesting. I think it is a good idea that mod_ssl grow capabilities to deal with key material other than PEM files on disk. The limitations: - Supports only one virtual host That would probably be a necessity. - Supports no keys from files at the moment Meaning you completely hacked that out, or just not in conjunction with HSM contained keys? We obviously couldn't do without the default PEM-files-on-disk case. - Loads HSM PIN from the OpenSSL.cnf file (No handler implemented at the moment) We *have* the passphrase dialog implementation for encrypted key files... could we leverage that to make the server ask for passphrases or PINs for HSM keys? That would not only benefit the P11 case, but also the existing CHIL support for the nCipher HSMs. - Certificate comes from file (not really a limitation...) Technically not, since the certificate is not sensitive data, but it could present problems from a management point of view. If you have multiple SSL hosts, how do you keep a particular certificate and its key together, and how would your successor or the remote hands guy in the data center at 3AM work that? What it does: - Private key is no longer in a file, it's in the secure HSM store - Private key operations are processed on the HSM Which is where we want them. Awesome. Did you intend to submit your patch for inclusion in the Apache code? Care to post some code so we can discuss it? It'd be easiest to discuss if you generated a patch against the Apache development trunk http://svn.apache.org/repos/asf/httpd/httpd/trunk instead of 2.2. Regards, Sander -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] 'clogging' input filters and the event MPM
+1 (concept)
On Jun 10, 2007, at 9:13 PM, Paul Querna wrote:
Attached is a patch that should let people run mod_ssl under the
Event MPM.
Previously, the event mpm would put a socket into its event thread to
wait for input, but due to issues with how mod_ssl might be buffering
data (or the entire request) in it, this would cause SSL'ized requests
to stall and fail with the event mpm.
The attach patch adds a new field, clogging_input_filters, to the
conn_rec. When this field is true, the event mpm will run a connection
just like the worker mpm is -- that is a single thread will run the
entire connection, including keepalives.
Thoughts on committing this to trunk?
Thanks,
-Paul
Index: server/mpm/experimental/event/event.c
===
--- server/mpm/experimental/event/event.c (revision 545614)
+++ server/mpm/experimental/event/event.c (working copy)
@@ -620,6 +620,16 @@
pt = cs-pfd.client_data;
}
+if (c-clogging_input_filters !c-aborted) {
+/* Since we have an input filter which 'cloggs' the input
stream,
+ * like mod_ssl, lets just do the normal read from input
filters,
+ * like the Worker MPM does.
+ */
+ap_run_process_connection(c);
+ap_lingering_close(c);
+return 0;
+}
+
read_request:
if (cs-state == CONN_STATE_READ_REQUEST_LINE) {
if (!c-aborted) {
Index: server/core.c
===
--- server/core.c (revision 545614)
+++ server/core.c (working copy)
@@ -3803,6 +3803,7 @@
c-cs-c = c;
c-cs-p = ptrans;
c-cs-bucket_alloc = alloc;
+c-clogging_input_filters = 0;
return c;
}
Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 545614)
+++ modules/http/http_core.c(working copy)
@@ -119,11 +119,17 @@
return DEFAULT_HTTP_PORT;
}
+static int ap_process_http_connection(conn_rec *c);
+
static int ap_process_http_async_connection(conn_rec *c)
{
request_rec *r;
conn_state_t *cs = c-cs;
+if (c-clogging_input_filters) {
+return ap_process_http_connection(c);
+}
+
AP_DEBUG_ASSERT(cs-state == CONN_STATE_READ_REQUEST_LINE);
while (cs-state == CONN_STATE_READ_REQUEST_LINE) {
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 545614)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1665,6 +1665,9 @@
filter_ctx-pbioWrite = BIO_new(bio_filter_out_method);
filter_ctx-pbioWrite-ptr = (void *)bio_filter_out_ctx_new
(filter_ctx, c);
+/* We insert a clogging input filter. Let the core know. */
+c-clogging_input_filters = 1;
+
ssl_io_input_add_filter(filter_ctx, c, ssl);
SSL_set_bio(ssl, filter_ctx-pbioRead, filter_ctx-pbioWrite);
Index: include/httpd.h
===
--- include/httpd.h (revision 545614)
+++ include/httpd.h (working copy)
@@ -1081,6 +1081,11 @@
int data_in_input_filters;
/** Is there data pending in the output filters? */
int data_in_output_filters;
+
+/** Are there any filters that clogg/buffer the input stream,
breaking
+ * the event mpm.
+ */
+int clogging_input_filters;
};
/**
Re: svn commit: r545379 - in /httpd/httpd/trunk: CHANGES modules/ssl/config.m4 modules/ssl/ssl_engine_config.c modules/ssl/ssl_private.h modules/ssl/ssl_scache.c modules/ssl/ssl_scache_memcache.c
Ruediger Pluem wrote:
+#else
+return SSLSessionCache: distcache support disabled;
Nitpicking: Should memcache instead of distcache.
Fixed in r545538.
Added: httpd/httpd/trunk/modules/ssl/ssl_scache_memcache.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_scache_memcache.c?view=autorev=545379
==
--- httpd/httpd/trunk/modules/ssl/ssl_scache_memcache.c (added)
+++ httpd/httpd/trunk/modules/ssl/ssl_scache_memcache.c Thu Jun 7 19:48:04
2007
@@ -0,0 +1,289 @@
+if (port == 0) {
+port = 11211; /* default port */
Shouldn't we use a define for the default port and refer to it instead of
using it directly?
Fixed in r546707.
+/* Should Max Conns be (thread_limit / nservers) ? */
+rv = apr_memcache_server_create(p,
+host_str, port,
+0,
+1,
+thread_limit,
+600,
+st);
Having at least some of the values configurable would be an enhancement
(Sorry for wanting to have
everything perfect from the start :-))
Nevertheless shouldn't we use defines for these default values (except
thread_limit of course)
and refer to them instead of using the values directly?
I've made them over-ridable compile time #defines for now -- making them
accessible from the config file with a reasonable syntax seems like a
painful challenge right now. (SSLSessionCache atm can only be configured
on a signle command/line atm).
+
+static char *mc_session_id2sz(unsigned char *id, int idlen,
+ char *str, int strsize)
+{
+char *cp;
+int n;
+
+cp = apr_cpystrn(str, MC_TAG, MC_TAG_LEN);
+for (n = 0; n idlen n (MC_KEY_LEN - MC_TAG_LEN); n++) {
Hm. It seems to me that our upper limit for n is (MC_KEY_LEN - MC_TAG_LEN)/2
and not (MC_KEY_LEN - MC_TAG_LEN) since every element of id consumes 2 bytes
in the
target buffer. Furthermore I would think that using (strsize - MC_TAG_LEN)/2
as a precalculated value would be even bettter.
+apr_snprintf(cp, strsize - (cp-str), %02X, id[n]);
Couldn't we replace
strsize - (cp-str)
just with
2
once the loop condition is fixed?
Yup. Changed in r546708.
+SSL_SESSION *ssl_scache_mc_retrieve(server_rec *s, UCHAR *id, int idlen)
+{
+SSL_SESSION *pSession;
+MODSSL_D2I_SSL_SESSION_CONST unsigned char *pder;
+apr_size_t der_len;
+SSLModConfigRec *mc = myModConfig(s);
+char buf[MC_KEY_LEN];
+char* strkey = NULL;
+apr_status_t rv;
+
+strkey = mc_session_id2sz(id, idlen, buf, sizeof(buf));
+
+if(!strkey) {
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+ scache_mc: Key generation borked.);
+return NULL;
+}
+
+rv = apr_memcache_getp(memctxt, mc-pPool, strkey,
Is this the correct pool to use? AFAICT the data stored in *pder
will only be used locally, because d2i_SSL_SESSION allocates
new memory to create the pSession object.
mc-pPool seems to be a pool with a long lifetime to me and I fear
that we introduce a memory leak here. How about a temporary subpool
if no other pool is at hand here?
I've re-worked pool allocations for both memcache and DBM backends, in
r545608 and r545610, but there are still some places in the DBM cache
where allocate from the configuration pool; However we should be good
now in the memcache cache backend.
+/* ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
+scache_mc: 'get_session' HIT); */
Why the comments above?
Useful for development/debugging, but they would be be hit 100% if they
weren't commented out
Thank You for reviewing,
-Paul
Re: svn commit: r546328 - in /httpd/httpd/trunk: CHANGES include/httpd.h modules/http/http_core.c modules/ssl/ssl_engine_io.c server/core.c server/mpm/experimental/event/event.c
Ruediger Pluem wrote:
Modified: httpd/httpd/trunk/include/httpd.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?view=diffrev=546328r1=546327r2=546328
==
--- httpd/httpd/trunk/include/httpd.h (original)
+++ httpd/httpd/trunk/include/httpd.h Mon Jun 11 17:32:24 2007
@@ -1081,6 +1081,11 @@
int data_in_input_filters;
/** Is there data pending in the output filters? */
int data_in_output_filters;
+
Nitpicking and style police: Empty lines should be completely empty and
should not contain spaces.
Fixed all of the empty line issues in r546632.
+/** Are there any filters that clogg/buffer the input stream, breaking
+ * the event mpm.
+ */
+int clogging_input_filters;
};
I am missing a minor bump since this is a change of the public API.
Added minor bump to trunk in r546650.
+static int ap_process_http_connection(conn_rec *c);
+
Nitpicking and style: I think you should either declare a prototype at the
top of the file just before all
function implementations start or you can just move
ap_process_http_connection here (which of course
may make backports of other future changes to this file harder and thus might
not be the best solution).
Yes, I was trying to avoid moving functions around. I've moved the decl
up to the top in r546632.
Modified: httpd/httpd/trunk/server/mpm/experimental/event/event.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/experimental/event/event.c?view=diffrev=546328r1=546327r2=546328
==
--- httpd/httpd/trunk/server/mpm/experimental/event/event.c (original)
+++ httpd/httpd/trunk/server/mpm/experimental/event/event.c Mon Jun 11
17:32:24 2007
@@ -620,6 +620,16 @@
pt = cs-pfd.client_data;
}
+if (c-clogging_input_filters !c-aborted) {
+/* Since we have an input filter which 'cloggs' the input stream,
+ * like mod_ssl, lets just do the normal read from input filters,
+ * like the Worker MPM does.
+ */
+ap_run_process_connection(c);
+ap_lingering_close(c);
+return 0;
I am not that deep into the event MPM code, but if we get into the lingering
close state of an async connection
(c-clogging_input_filters = 0 cs-state == CONN_STATE_LINGER) we do the
following:
ap_lingering_close(c);
apr_pool_clear(p);
ap_push_pool(worker_queue_info, p);
return 1;
Here is what the return value does:
rv = process_socket(ptrans, csd, cs, process_slot, thread_slot);
if (!rv) {
requests_this_child--;
}
It is a bad system, and all it does is keep the stats right for the
number of connections handled.
Return 1 means the client was not completely handled, and that the
socket is still being 'worked on' by someone.
Return 0 means its completely done.
And yes, requests_this_child counts down, because it is crazy.
I fear that we will leak pools and memory if we don't clear them and push
them back in the queue.
To be honest I have no idea why we do a return 1 in this situtaion. It seems
wrong to me and should
be return 0 instead.
Another alternative would be to do
cs-state = CONN_STATE_LINGER
I've changed to this in r546715.
Thanks Again,
-Paul
code docs corrections for FollowSymLinks and SymLinksIfOwnerMatch
Reading resolve_symlink() in server/request.c, it first checks
OPT_SYM_LINKS. If OPT_SYM_LINKS is set, it never does the checks for link
ownership. It checks link ownership only when OPT_SYM_OWNER is set and
OPT_SYM_LINKS is unset.
Based on this logic, the following changes should be made to the code and
documentation:
- 1 -
http://httpd.apache.org/docs/2.2/mod/core.html#options
Documentation for SymLinksIfOwnerMatch
Current Text: The server will only follow symbolic links for which the
target file or directory is owned by the same user id as the link.
Corrected Text: The server will follow symbolic links for which the target
file or directory is owned by the same user id as the link.
This change removes the word only. This changes is needed because if
FollowSymLinks is set, all sym links will be followed, even ones without the
same owner user id.
- 2 -
mod_rewrite.c lines 4461 to 4468 currently read:
if (!(ap_allow_options(r) (OPT_SYM_LINKS | OPT_SYM_OWNER))) {
/* FollowSymLinks is mandatory! */
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
Options FollowSymLinks or SymLinksIfOwnerMatch is off
which implies that RewriteRule directive is forbidden:
%s, r-filename);
return HTTP_FORBIDDEN;
}
The options test is correct, however, the error message should be changed
to: Options FollowSymLinks and SymLinksIfOwnerMatch are both off which
implies that RewriteRule directive is forbidden. This message describes
what actually happens: RewriteEngine can currently be enabled if either
FollowSymlinks or SymLinksIfOwnerMatch is enabled. It only displays the
error if both are disabled.
request.c lines 930 to 934 currently read:
if (r-finfo.filetype
#ifdef CASE_BLIND_FILESYSTEM
(filename_len = canonical_len)
#endif
((opts.opts (OPT_SYM_OWNER | OPT_SYM_LINKS)) ==
OPT_SYM_LINKS))
The last line should read
(opts.opts OPT_SYM_LINKS) )
This change accurately reflects the logic of resolve_symlink(); if
OPT_SYM_LINKS is set, then the state of OPT_SYM_OWNER does not matter.
I will also be submitting a correction for the open attempt on
../file.html/.htaccess, but I wanted to get this issue out of the way
first.
Allen
Re: httpd attempts to open file.html/.htaccess (is this a bug?)
Allen Pulsifer wrote: Hello Paul and Dev List, Thanks for the reply. I checked out the links and did some code tracing with the debugger. As one of the links pointed out, the problem is in the block of code attached below from ap_directory_walk() in server/request.c just a quick note to thank you, Allen, for the most thorough analysis of the optimizations of dir_walk. I'm partially to blame (followed by others who attempted to optimized further :-) and would love to see an optimization model which is more generic, e.g. not engangled with the specifics of 'I'm for directories' or 'I'm for patterns'... It's great to have your reference to help debug and to correct the functioning of dir_walk, and we hope you'll participate in testing/confirming any proposed fixes. My thought for the next-step is to divide dir_walk into cache code (was this opaque pattern hit before?) and into dir/file handling code, with fixes (which your patch suggests) and perhaps even clearly splitting out the REG v.s. DIR into some separate phases. We are open to all suggestions.
Re: Module to allow authentication with sasl
Giuliano Gavazzi wrote: I read the announcement of mod_sasl_auth. I admit I haven't yet examined the question further, but wasn't SASL a no go for authentication because of apache threads? That could explain why I couldn't find an existing mod_auth_sasl module! However, I'm fairly confident that the code should be thread safe (Touch wood!) and it seems to be running fine on my server! (Touches wood again to be on the safe side!). I have been running a mod_authnz_sasl I wrote, for almost eight months but never dared to make it public for the above concern... I've had a quick look and I'm a bit confused why you're connecting directly to the saslauthd socket - if you use the Cyrus-SASL server library then you can use the option saslauthd_path: in the /usr/lib/sasl2/SERVICE.conf file. However, this is my first attempt at writing a Cyrus-SASL program so there's a good chance that I've missed something. There are some clear differences in approach between the two. Good that we have chosen different names! Like mod_auth_imap, the module I borrowed most of the code from, mine just deals with bog standard plain text passwords with no groups. By comparison, I think yours even includes the kitchen sink! :- Take care, Ben
Outgoing filter ends in oom
Hi all, I have written this email already to the user ml but there they said I should talk to you: I have a problem concerning the outgoing filter of apache 2.2.3 with mpm worker from the debian repository. the problem is the following: when included a output filter, perl or c based, i get sometimes the situation that a single apache process allocates all available memory and swap. This ends in a oom situation. I tried using a different mpm: prefork, but there is the problem that the allocation process happens more often. With worker it happens 1 time in 4-7 days. I also tried limiting the allocation of memory by using the following global configuration settings: RLimitMEM 1 2 RLimitCPU 90 120 MaxMemFree 50 Is there a possibility for preventing such a problem? I didn't find such a problem using google and yahoo. I would be very thankful for every help. If you need more information I will try to give them. Best regards Oliver
