Re: Help: How to call function on Apache quitA
On Thu, 15 Nov 2007 00:15:17 -0800 (PST) Erik Lotspeich [EMAIL PROTECTED] wrote: The basic question is: how to execute code when Apache quits. Register a cleanup function on the process pool. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Apache 2.0 module skeleton
Graf László wrote: Hi all, Can somebody give a project skeleton for Apache 2.0 module? The tool is apxs. Google it for more information. You might even find a link that looks like : http://archive.apache.org/dist/perl/win32-bin/ where you can download the apxs tool. DISCLAIMER : I have not run this on Windows due to myself not being a proponent of the said OS. I cannot verify if this tool actually works in this environment. My linux/BSD/Solaris/AIX/etc command I typically use to generate a skeleton : apxs -g -n mod_skeleton Joe -- Joseph Lewis http://sharktooth.org/ Divide the fire, and you will sooner put it out. - Publius Syrus
Re: Apache 2.0 module skeleton
Thank you Lewis. Joe Lewis írta: Graf László wrote: Hi all, Can somebody give a project skeleton for Apache 2.0 module? The tool is apxs. Google it for more information. You might even find a link that looks like : http://archive.apache.org/dist/perl/win32-bin/ where you can download the apxs tool. DISCLAIMER : I have not run this on Windows due to myself not being a proponent of the said OS. I cannot verify if this tool actually works in this environment. My linux/BSD/Solaris/AIX/etc command I typically use to generate a skeleton : apxs -g -n mod_skeleton Joe -- Graf László
httpd/sandbox/amsterdam/d/modules/proxy/mod_serf.c?revision=595110view=markup
-if (APR_BRIGADE_SENTINEL(ctx-bb)) {
+if (APR_BRIGADE_EMPTY(ctx-bb)) {
+*len = 0;
+return APR_EOF;
+}
+
+if (APR_BUCKET_IS_EOS(APR_BRIGADE_FIRST(ctx-bb)) ||
+AP_BUCKET_IS_EOR(APR_BRIGADE_FIRST(ctx-bb))) {
*len = 0;
return APR_EOF;
Why do we not put this in one if block like?
if (APR_BRIGADE_SENTINEL(ctx-bb) ||
APR_BUCKET_IS_EOS(APR_BRIGADE_FIRST(ctx-bb)) ||
AP_BUCKET_IS_EOR(APR_BRIGADE_FIRST(ctx-bb))) {
*len = 0;
return APR_EOF;
}
@@ -567,8 +567,21 @@
return APR_SUCCESS;
}
-if (mode == AP_MODE_EATCRLF || mode == AP_MODE_EXHAUSTIVE ||
-mode == AP_MODE_SPECULATIVE) {
+if (mode == AP_MODE_SPECULATIVE) {
+const char *data;
+apr_size_t len;
+apr_bucket *b;
+serf_bucket_t *sb;
+
+ctx-serf_bucket_status = serf_bucket_read(ctx-serf_in_bucket,
+ readbytes, data, len);
+
+sb = serf_bucket_simple_create(data, len, NULL, NULL,
ctx-serf_bkt_alloc);
+serf_bucket_aggregate_prepend(ctx-serf_in_bucket, sb);
Hm. Don't we need the following lines here?
b = apr_bucket_transient_create(data, len, f-c-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, b);
Otherwise I guess we read the data but do not return it :-).
+return APR_SUCCESS;
+}
+
+if (mode == AP_MODE_EATCRLF || mode == AP_MODE_EXHAUSTIVE) {
abort();
}
}
Regards
Rüdiger
Re: keepalive connections and exiting MPM processes
On Nov 13, 2007 10:38 AM, Jeff Trawick [EMAIL PROTECTED] wrote:
On Nov 13, 2007 8:57 AM, Plüm, Rüdiger, VF-Group
[EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Jeff Trawick
Gesendet: Dienstag, 13. November 2007 14:31
An: dev@httpd.apache.org
Betreff: keepalive connections and exiting MPM processes
When the MPM process handling the connection is or will be exiting, we
can incorrectly tell the client that the connection will be held open
after the current request. This can result in user intervention
(retry the POST?) or failures for some requests sent subsequently on
that connection.
...
It isn't so clear how to handle the remaining window, in which the MPM
process starts exiting while we send the response (and after we've
already determined the keepalive setting).
From ap_process_http_connection():
if (r-status == HTTP_OK) {
cs-state = CONN_STATE_HANDLER;
ap_process_request(r);
r = NULL;
}
if (c-keepalive != AP_CONN_KEEPALIVE || c-aborted)
break;
XXX
We could skip checking for graceful exit here since
it is checked
as part of the keepalive determination, but the MPM process
could remain active much longer than expected (maybe we just
downloaded a very large file).
XXX
if (ap_graceful_stop_signalled())
break;
For the remaining timing window, I'm afraid that a vhost-specific
setting is needed to control whether we respect the connection
keepalive setting or the MPM state. (The latter is apparently good
I guess we can leave it as it is in this situation. Although we SHOULD
send connection: close if want to close the connection it is no MUST
(8.1.2.1, last sentence first paragraph). And for pipelined requests the
client must be prepared to resend anyway if we do not process all pipelined
requests (8.1.2.2).
Apart from the SHOULD vs. MUST is the end-user issue when the client
software can't or won't retry automatically when confronted with a
validly-dropped connection ;)
Here's a patch to address that issue:
http://people.apache.org/~trawick/keepalive.txt
(KeepAliveWhileExiting On|Off, default Off)
It comes down to this check in ap_process_http_connection():
while ((r = ap_read_request(c)) != NULL) {
...
if (c-keepalive != AP_CONN_KEEPALIVE || c-aborted)
break;
...
if (!c-base_server-keep_alive_while_exiting
ap_graceful_stop_signalled())
break;
}
The only commentary I've seen on the general idea so far is that the
RFC doesn't force us to respect that persistence.
Re: httpd/sandbox/amsterdam/d/modules/proxy/mod_serf.c?revision=595110view=markup
On Nov 15, 2007, at 7:02 AM, Plüm, Rüdiger, VF-Group wrote:
@@ -567,8 +567,21 @@
return APR_SUCCESS;
}
-if (mode == AP_MODE_EATCRLF || mode == AP_MODE_EXHAUSTIVE ||
-mode == AP_MODE_SPECULATIVE) {
+if (mode == AP_MODE_SPECULATIVE) {
+const char *data;
+apr_size_t len;
+apr_bucket *b;
+serf_bucket_t *sb;
+
+ctx-serf_bucket_status = serf_bucket_read(ctx-
serf_in_bucket,
+ readbytes,
data, len);
+
+sb = serf_bucket_simple_create(data, len, NULL, NULL, ctx-
serf_bkt_alloc);
+serf_bucket_aggregate_prepend(ctx-serf_in_bucket, sb);
Hm. Don't we need the following lines here?
b = apr_bucket_transient_create(data, len, f-c-
bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, b);
Otherwise I guess we read the data but do not return it :-).
I don't follow that, but I'm still not quite fully awake yet...
Apache 2.0 module skeleton
Hi all, Can somebody give a project skeleton for Apache 2.0 module? I need it for the development of a custom module for Apache 2.2.6 on Windows XP (SP2) and I have access to Microsoft Visual Studio 2005 and Microsoft Visual C++ 6.0. Thank you, -- Graf László
Re: [PROPOSAL] Adoption of mod_dns to httpd?
On Nov 14, 2007, at 9:17 AM, Justin Erenkrantz wrote: [X] Immediate adoption as a subproject (pending IP clearance via the incubator) - But, no separate mailing lists and no separate committers +1 S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Httpd 'Amsterdam' commits
Hi, Seems that there are lots of commits made recently to that branch (IIUC Apache 3) However I simply cannot recall there was any discussion except the one in the https://svn.apache.org/repos/asf/httpd/sandbox/amsterdam/ROADMAP So, a simple question, what are we doing? What are the goals and are we simply doing 2.3 or 3.x? Seems to me that we are simply patching the 2.2 and hope something better will came out of it. If the guys committing those stuff can share some light to the rest of us, perhaps we could participate as well. Regards, Mladen
Re: Httpd 'Amsterdam' commits
On Nov 15, 2007 12:10 PM, Mladen Turk [EMAIL PROTECTED] wrote: If the guys committing those stuff can share some light to the rest of us, perhaps we could participate as well. The path we're going down (for now) is making serf the core input/output filtering mechanism. In a conversation here in Atlanta, I was able to convince myself and a few other people that we could transition filters/brigades into serf buckets. We might want to go for a clean break, but we're just exploring at this point. But, the admitted goal is to remove all input and output filters and replace them with serf buckets. At this point, the core input/output filters are gone. Next up is replacing the HTTP filters... We're punting on SSL for now - Serf can already do that; but we'd like to get a bit higher up in the chain before complicating things with SSL. -- justin
Re: httpd/sandbox/amsterdam/d/modules/proxy/mod_serf.c?revision=595110view=markup
On 11/15/2007 04:26 PM, Jim Jagielski wrote:
On Nov 15, 2007, at 7:02 AM, Plüm, Rüdiger, VF-Group wrote:
@@ -567,8 +567,21 @@
return APR_SUCCESS;
}
-if (mode == AP_MODE_EATCRLF || mode == AP_MODE_EXHAUSTIVE ||
-mode == AP_MODE_SPECULATIVE) {
+if (mode == AP_MODE_SPECULATIVE) {
+const char *data;
+apr_size_t len;
+apr_bucket *b;
+serf_bucket_t *sb;
+
+ctx-serf_bucket_status = serf_bucket_read(ctx-serf_in_bucket,
+ readbytes, data,
len);
+
+sb = serf_bucket_simple_create(data, len, NULL, NULL,
ctx-serf_bkt_alloc);
+serf_bucket_aggregate_prepend(ctx-serf_in_bucket, sb);
Hm. Don't we need the following lines here?
b = apr_bucket_transient_create(data, len, f-c-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, b);
Otherwise I guess we read the data but do not return it :-).
I don't follow that, but I'm still not quite fully awake yet...
Well, as far as I understand AP_MODE_SPECULATIVE its purpose is to read data
and return
it to the caller, but leave the data in the input filter chain such that a
following read
(or better a get_brigade) from the input filter chain returns the same data
again.
And in the case above we only read the data from ser_in_bucket, but unlike in
the AP_MODE_READBYTES
case we do not create a transient bucket with data and add it to the bb
brigade. So the
caller gets back an empty brigade with no data.
Regards
Rüdiger
Re: httpd/sandbox/amsterdam/d/modules/proxy/mod_serf.c?revision=595110view=markup
On Nov 15, 2007, at 7:02 AM, Plüm, Rüdiger, VF-Group wrote:
-if (APR_BRIGADE_SENTINEL(ctx-bb)) {
+if (APR_BRIGADE_EMPTY(ctx-bb)) {
+*len = 0;
+return APR_EOF;
+}
+
+if (APR_BUCKET_IS_EOS(APR_BRIGADE_FIRST(ctx-bb)) ||
+AP_BUCKET_IS_EOR(APR_BRIGADE_FIRST(ctx-bb))) {
*len = 0;
return APR_EOF;
Why do we not put this in one if block like?
LOL... I saw the commit message and thought the same thing and
actually changed it before I actually checked dev@ :) :)
Re: Help: How to call function on Apache quitA
Hi Nick, Thank you for your response. I tried this approach initially. I may have been using it incorrectly, however. What I tried was setting up the cleanup function with the process pool itself as data. The reason for this is that I wanted to retrieve some data via apr_pool_userdata_get() in order to do the necessary cleanup. This didn't work -- is it possible that the pool is already partial destroyed when the cleanup function is called? I noticed that the Apache logging facilities don't appear to work in the cleanup function either. I am also curious why apr_pool_note_subprocesses() does not appear to work. This function seems ideal for my purpose; am I using it incorrectly? Your book is excellent, by the way. Having a clearly-written definitive resource has saved me countless hours. Regards, Erik. On Thu, 15 Nov 2007, Nick Kew wrote: On Thu, 15 Nov 2007 00:15:17 -0800 (PST) Erik Lotspeich [EMAIL PROTECTED] wrote: The basic question is: how to execute code when Apache quits. Register a cleanup function on the process pool.
Re: [PROPOSAL] Adoption of mod_dns to httpd?
Guenter Knauf wrote: Hi Issac, I'd like to offer up mod_dns (http://www.beamartyr.net/mod-dns-1.02.tar.bz2) for inclusion in the httpd project (either as a mod_ftp-like subproject, or as module with the standard distribution - whatever people prefer). Can people vote for what they're most comfortable with? [x ] Immediate adoption as a subproject (pending IP clearance via the incubator) I've just tried to compile the mod for NetWare, but my picky compiler wasnt fine with some type mismatches, mostly signed-unsigned; here's a diff which shows what I needed to get it compiled: http://www.gknw.net/test/mod_dns/ please check. I would also prefer to compile with vpath, and therefore the '../rr.h' include is a but ugly; would be nice if you agree to change this to just 'rr.h'. Also would be more nice if you rename the folder to use an underscore as usual, and use a version number like 1.0.2. Guenter. Guenter, I don't think that #include rr.h would work with apxs (which is the build method that I wrote it around). For the type stuff, I'll look at it real soon. Meanwhile, did your patch solve the following? rr/rr.c: In function 'dns_rr_unserialize': rr/rr.c:194: warning: passing argument 3 of 'rrr-rdata-unserialize' from incompatible pointer type I'm not sure how well NetWare's going to be supported unless someone helps write apr_sendtov for NetWare (the only implementation that I couldn't figure out how to write); without it, you'll have TCP support only. Issac
--enable-distcache
expat_ver=2.0.0 apr_config=apr-1-config apu_config=apu-1-config httpd_ver=2.2.6 cd $HOME/build/dist ; fetch -mva http://mirror.olnevhost.net/pub/apache/httpd/httpd-$httpd_ver.tar.gz cd $HOME/build/src ; tar -xvzf $HOME/build/dist/httpd-$httpd_ver.tar.gz CFLAGS=-O2 -fno-strict-aliasing -pipe -DAP_UNSAFE_ERROR_LOG_UNESCAPED ./configure \ --prefix=/software/httpd/2.2.6/prefork \ --with-expat=/software/expat/2.0.0 \ --with-perl=/software/perl/5.5.8/bin/perl \ --with-apr=/software/apr/1.2.8/bin/apr-1-config \ --with-apr-util=/software/apr-util/1.2.8/bin/apu-1-config \ --with-mpm=prefork \ --with-ssl=/usr \ --enable-ssl --enable-distcache \ checking whether to enable mod_ssl... checking dependencies checking for SSL/TLS toolkit base... /usr checking for OpenSSL version... checking openssl/opensslv.h usability... yes checking openssl/opensslv.h presence... yes checking for openssl/opensslv.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes OK checking openssl/engine.h usability... yes checking openssl/engine.h presence... yes checking for openssl/engine.h... yes gnome-config: not found checking for SSLeay_version in -lcrypto... yes checking for SSL_CTX_new in -lssl... yes checking for ENGINE_init... yes checking for ENGINE_load_builtin_engines... yes checking for SSL_set_cert_store... no adding -I/usr/include to INCLUDES adding -L/usr/lib to LDFLAGS forcing SSL_LIBS to -lssl -lcrypto gnome-config: not found forcing MOD_SSL_LDADD to $(SSL_LIBS) checking whether Distcache is required... yes (specified) checking distcache/dc_client.h usability... no checking distcache/dc_client.h presence... no checking for distcache/dc_client.h... no configure: error: distcache support failed: can't include distcache headers Sure enough, this file is not in the tarball or SVN. Has it been this way since 2003 ? http://marc.info/?l=apache-httpd-devm=106984835501531w=2 -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Senior System Admin - Riderway, Inc. http://riderway.com 1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: httpd/sandbox/amsterdam/d/modules/proxy/mod_serf.c?revision=595110view=markup
On Nov 15, 2007, at 12:17 PM, Ruediger Pluem wrote: I don't follow that, but I'm still not quite fully awake yet... Well, as far as I understand AP_MODE_SPECULATIVE its purpose is to read data and return it to the caller, but leave the data in the input filter chain such that a following read (or better a get_brigade) from the input filter chain returns the same data again. And in the case above we only read the data from ser_in_bucket, but unlike in the AP_MODE_READBYTES case we do not create a transient bucket with data and add it to the bb brigade. So the caller gets back an empty brigade with no data. Ahh yes, I see know. Yep. This appears to be the case that we're dropping bytes.
2.2.7 seems to come in sight: Digest of STATUS
Now that the TR of APR / APR-UTIL is in progress (Thanks Other Bill) httpd 2.2.7 seems to come in sight. There are about 10 backport proposals in the STATUS file that are only missing one vote. So come on it is voting and review time guys :-)). There is one backport proposal (http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix-log.c.patch) by Other Bill for core log.c that might be a show stopper for 2.2.7 and is waiting for reply / discussion and two votes. Regards Rüdiger
Re: svn commit: r595464 - /httpd/httpd/branches/1.3.x/src/main/http_main.c
On Thu, Nov 15, 2007 at 09:31:17PM -, [EMAIL PROTECTED] wrote:
Modified: httpd/httpd/branches/1.3.x/src/main/http_main.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/main/http_main.c?rev=595464r1=595463r2=595464view=diff
==
--- httpd/httpd/branches/1.3.x/src/main/http_main.c (original)
+++ httpd/httpd/branches/1.3.x/src/main/http_main.c Thu Nov 15 13:31:15 2007
@@ -2661,7 +2661,6 @@
if (status == SERVER_DEAD) {
ss-my_access_count = 0L;
ss-my_bytes_served = 0L;
-ap_scoreboard_image-parent[child_num].pid = 0;
}
ss-conn_count = (unsigned short) 0;
ss-conn_bytes = (unsigned long) 0;
By the by, I just noticed that we have a sh*tload of tabs in various
1.3 files... should be take the time to actually detab? Or let float...
I'm 0 either way.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
Great is the guilt of an unnecessary war ~ John Adams
Re: 2.2.7 seems to come in sight: Digest of STATUS
On Nov 15, 2007, at 4:22 PM, William A. Rowe, Jr. wrote: Ruediger Pluem wrote: Now that the TR of APR / APR-UTIL is in progress (Thanks Other Bill) httpd 2.2.7 seems to come in sight. There are about 10 backport proposals in the STATUS file that are only missing one vote. So come on it is voting and review time guys :-)). There is one backport proposal (http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix- log.c.patch) by Other Bill for core log.c that might be a show stopper for 2.2.7 and is waiting for reply / discussion and two votes. As soon as a snapshot of mod_ftp is created (to start discussing release 1) I'll have the win machine up and testing the messes in pipe inheritence, and handing off the last two patches I'd like considered (for log, and the mpm). My plan is to take time early tomorrow and over the weekend to test and vote, in hopes of releasing 2.2.7 say around the top of Dec...
Re: httpd/sandbox/amsterdam/d/modules/proxy/mod_serf.c?revision=595110view=markup
On Nov 15, 2007 12:17 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: And in the case above we only read the data from ser_in_bucket, but unlike in the AP_MODE_READBYTES case we do not create a transient bucket with data and add it to the bb brigade. So the caller gets back an empty brigade with no data. Yup. My bad. Fixed in r595396. -- justin
Re: 2.2.7 seems to come in sight: Digest of STATUS
Ruediger Pluem wrote: Now that the TR of APR / APR-UTIL is in progress (Thanks Other Bill) httpd 2.2.7 seems to come in sight. There are about 10 backport proposals in the STATUS file that are only missing one vote. So come on it is voting and review time guys :-)). There is one backport proposal (http://people.apache.org/~wrowe/httpd-2.0-2.2-procattr-bugfix-log.c.patch) by Other Bill for core log.c that might be a show stopper for 2.2.7 and is waiting for reply / discussion and two votes. As soon as a snapshot of mod_ftp is created (to start discussing release 1) I'll have the win machine up and testing the messes in pipe inheritence, and handing off the last two patches I'd like considered (for log, and the mpm). Bill
Re: Httpd 'Amsterdam' commits
Justin Erenkrantz wrote: The path we're going down (for now) is making serf the core input/output filtering mechanism. In a conversation here in Atlanta, I was able to convince myself and a few other people that we could transition filters/brigades into serf buckets. We might want to go for a clean break, but we're just exploring at this point. But, the admitted goal is to remove all input and output filters and replace them with serf buckets. Is the plan to remove the filtering mechanism entirely, or just the filters that make HTTP happen? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
mod_ldap: server_config structure part of the API?
All, mod_ldap has it's own server_config struct defined in httpd/include/util_ldap.c -- does this location implicitly make the server config structure part of the API? If So, what kind of one-time bump would it take to pull this out of the public header? -- Eric Covener [EMAIL PROTECTED]
Re: [PROPOSAL] Adoption of mod_dns to httpd?
Hi Issac, Issac Goldstand schrieb: I don't think that #include rr.h would work with apxs (which is the build method that I wrote it around). no problem; you can just tell apxs to use an include path; I've just tried on my SuSE box with: apxs2 -c -I . *.c rr/*.c build.log 21 here's the buildlog of the unpatched version: http://www.gknw.net/test/mod_dns/build.log and here after applying my _new_ patch (since gcc found some more things I did fix these too, and created a new diff; now only the implicit warning remains): http://www.gknw.net/test/mod_dns/build_patched.log and here the patched sources: http://www.gknw.net/test/mod_dns/mod_dns-1.02.tar.gz For the type stuff, I'll look at it real soon. Meanwhile, did your patch solve the following? rr/rr.c: In function 'dns_rr_unserialize': rr/rr.c:194: warning: passing argument 3 of 'rrr-rdata-unserialize' from incompatible pointer type yes, there was a void* cast needed. I'm not sure how well NetWare's going to be supported unless someone helps write apr_sendtov for NetWare (the only implementation that I couldn't figure out how to write); without it, you'll have TCP support only. what was the problem? I can tell you that NetWare supports both Winsock2 and BSD sockets; we use by default most of the Win32 socket stuff, but can switch over to using Unix socket stuff (with separate builds, not within one build). Guenter.
