Re: apr_pollcb
Can you describe "lagging" in more detail? None of the poll related code has a high rate of change (except for the relatively new z/OS backend): https://github.com/apache/apr/tree/trunk/poll/unix Also are you looking specifically on Linux? (epoll backend?) or others On Mon, Mar 9, 2015 at 11:04 AM, Jim Jagielski wrote: > As far as I can tell, there are no real consumers of apr_pollcb_*() > other than Motorz (and Simple)... Not sure, but it looks like the > pollcb stuff may be lagging, since I'm getting some weird behavior > when using that impl. So I'll likely be moving Motorz off of > pollcb and use the "traditional" impl which has been proven in > Event. > >
Re: apr_pollcb
right, libuv[1] is a good example of an IO completion API[2] that works across both epoll/kqueue and IOCP. There have been a couple offhand discussions about libuv on httpd-dev, but no one is clamoring for adoption. APR currently has no such abstraction. pollcb was added to provide a polling API that was lock free, allowed cross-thread addition and didn't keep extra data structures around for N sockets under management. (this contrasts to APR's pollset which has locks, uses a couple RINGs of structures to keep track of things, etc) [1] - https://github.com/libuv/libuv [2] - http://nikhilm.github.io/uvbook/filesystem.html#buffers-and-streams On Thu, Mar 12, 2015 at 3:40 PM, Ivan Zhakov wrote: > On 9 March 2015 at 20:04, Jim Jagielski wrote: > > As far as I can tell, there are no real consumers of apr_pollcb_*() > > other than Motorz (and Simple)... Not sure, but it looks like the > > pollcb stuff may be lagging, since I'm getting some weird behavior > > when using that impl. So I'll likely be moving Motorz off of > > pollcb and use the "traditional" impl which has been proven in > > Event. > > > > I'd like to share some thoughts about pollcb as Windows developer. > Most efficient way to handle a lot of connections on Windows is I/O > completion ports (IOCP). They are like epoll, but different. Here is > good writeup about difference [1]. In short: IOCP provides > notification when I/O completes, while epoll provides notifications > when socket is ready to perform I/O operation. It would require > additional buffer to implement pollcb using IOCP on Windows. Or > APR/HTTPD should have different abstraction that is responsible for > I/O and waiting for completion. > > [1] > http://www.ulduzsoft.com/2014/01/practical-difference-between-epoll-and-windows-io-completion-ports-iocp/ > > -- > Ivan Zhakov >
Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h
It seems reasonable to focus on ALPN support, and generally dropping
NPN from trunk. NPN is already on a decline, and won't be used going
forward.
On Thu, Apr 2, 2015 at 12:44 AM, Stefan Eissing
wrote:
> Any reason to differ from trunk in 2.4?
>
> The people using spdy already in a 2.4 will most likely have the NPN patch
> deployed, so they'll have it easy with the trunk changes. The only one using
> the alpn patch, I know of, is myself in mod_h2. And that has already been
> adapted.
>
> So, I myself see no reason to not bring the trunk change into 2.4.
>
>> Am 01.04.2015 um 22:33 schrieb Jim Jagielski :
>>
>> Yeah, I agree. Right now, trunk pretty much uses
>>
>> #ifdef HAVE_TLS_ALPN
>> blah blah
>> #endif
>> #ifdef HAVE_TLS_NPN
>> blah2 blah2
>> #endif
>>
>> Instead of
>>
>> #if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)
>>
>> so that "ripping out" NPN would be easier. The question is
>> which to use for 2.4...
>>
>>> On Apr 1, 2015, at 1:59 PM, Stefan Eissing
>>> wrote:
>>>
>>> Well, I took the trunk version, diffed to 2.4.12 and made a patch for my
>>> sandbox build (removed the non alpn/npn parts). That works for mod_h2 after
>>> adding callbacks for the npn stuff.
>>>
>>> I have no real pref to keep npn and alpn separate or not. my thought when
>>> merging these was that npn will go away rather soon as alpn is supposed to
>>> replace it and is afaik the cryptographically more secure way (i think npn
>>> is prone to mitm downgrade attacks).
>>>
>>> cheers,
>>> Stefan
>>>
>>>
>>>
Am 01.04.2015 um 19:28 schrieb Jim Jagielski :
Yeah, there is some "overlap" which I'm trying to grok,
since trunk had NPN but not ALPN, so I tried to have the
ALPN stuff self-contained. But not sure if that's the best
way since, for example, alpn_proposefns is adjusted
in ssl_callback_AdvertiseNextProtos(), but that is a
NPN "only" function in trunk, so it uses npn_proposefns.
I'm thinking that in trunk we shouldn't think of
NPN and ALPN as "distinct".
> On Apr 1, 2015, at 12:47 PM, Rainer Jung wrote:
>
> Hi Stefan,
>
>> Am 01.04.2015 um 18:22 schrieb Stefan Eissing:
>> Jim,
>>
>> today I converted your commit to a path on 2.4.12 and tested it with
>> mod_h2. All fine!
>>
>> Then I got a trouble report that alpn negotiation always selected
>> "http/1.1" unless SSLAlpnPreference configured something else. This is
>> due to the deterministic ordering and "http/1.1." > "h2". So, I made a
>> slight modification, attached below.
>
> Maybe related but concerning NPN: There was a difference between the NPN
> parts of your original Bugzilla attachment and what was already in
> mod_ssl trunk and therefore was not applied. In your attachment, there
> was some code for sorting in ssl_callback_AdvertiseNextProtos() which
> IMHO does not exist in trunk. Is that part necessary?
>
> A second difference: your original addition to ssl_engine_io.c had the
> NPN and the ALPN parts merged in the same code block. In trunk those are
> now two separate pieces coming after each other.
>
>> --- modules/ssl/ssl_engine_kernel.c2015-04-01 15:23:48.0
>> +0200
>> +++
>> ../../mod-h2/sandbox/httpd/gen/httpd-2.4.12/modules/ssl/ssl_engine_kernel.c
>> 2015-04-01 17:53:03.0 +0200
>> @@ -2177,7 +2152,7 @@
>> }
>>
>> /*
>> - * Compare to ALPN protocol proposal. Result is similar to strcmp():
>> + * Compare two ALPN protocol proposal. Result is similar to strcmp():
>> * 0 gives same precedence, >0 means proto1 is prefered.
>> */
>> static int ssl_cmp_alpn_protos(modssl_ctx_t *ctx,
>> @@ -2254,14 +2229,8 @@
>> i += plen;
>> }
>>
>> -/* Regardless of installed hooks, the http/1.1 protocol is always
>> - * supported by us. Add it to the proposals if the client also
>> - * offers it. */
>> proposed_protos = apr_array_make(c->pool, client_protos->nelts+1,
>>sizeof(char *));
>> -if (ssl_array_index(client_protos, alpn_http1) >= 0) {
>> -APR_ARRAY_PUSH(proposed_protos, const char*) = alpn_http1;
>> -}
>>
>> if (sslconn->alpn_proposefns != NULL) {
>> /* Invoke our alpn_propos_proto hooks, giving other modules a
>> chance to
>> @@ -2280,9 +2249,16 @@
>> }
>>
>> if (proposed_protos->nelts <= 0) {
>> -ap_log_cerror(APLOG_MARK, APLOG_ERR, 0, c, APLOGNO(02839)
>> - "none of the client alpn protocols are
>> supported");
>> -return SSL_TLSEXT_ERR_ALERT_FATAL;
>> +/* Regardless of installed hooks, the http/1.1 protocol is
>> always
>> + * supported by us. Choose it if none other matches. */
>> +if (ssl_array_index(
Re: XSLT filter for httpd
On Mon, Oct 19, 2015 at 7:54 AM, Nick Kew wrote: > On Mon, 19 Oct 2015 15:39:06 +0200 > Graham Leggett wrote: > >> > Note, mod_transform is GPL. Originally my decision when I released >> > its earlier predecessor, before I was part of the dev@httpd team. >> > I'd be happy to re-license it as Apache, and I don't think >> > any of my co-developers would object. >> >> I’ve been using mod_transform v0.6.0 for a while, and have wanted to develop >> it further. It would be a great starting point. > > I have a distant recollection of consulting Paul and Edward about > re-licensing, then dropping the ball on it. IIRC the outcome was, > they were both happy to re-license, but there had also been one > or two third-party patches raising a questionmark over whether we > should consult anyone else. > > Cc: Paul. Do you recollect that? You still in contact with Edward? I have no objections to relicensing mod_transform, Adding Edward and Christian, the only other people with commits in afaik: https://github.com/OutOfOrder/mod_transform/commits/master I'm not sure I believe in belongs in HTTP Server project itself, I think it has had a fine life as an external module, and github is doing fine for basic maintenance, but I'll bow to people with energy if y'all really want it under the ASF domain.
Re: how to set external module variable in other httpd-module
Lubo wrote: > I need to change this variable from within this module mod_vdbh. The > idea is, that every virtual host should have his own open_basedir > value (/mnt/webs/user1, /mnt/webs/user2), etc... > > Is it possible ? I spend some time with apache-API, documentation, > programming, but I have no idea, how can I do that ... Not only is it possible, I wrote one. This code is originally based off of mod_vdbh, but I converted it to use libdbi and added a few other things. It includes the ability to set PHP safemode/open_basedir values based on database records. This code is very "alpha" and was written more as a proof of concept, It does however "work for me". It doesn't cache the results, so deploying this on a live server is questionable. YMMV. Completely Unsupported. Etc. Source: http://force-elite.com/~chip/mod_vhost_dbi.tar.gz I know many people want this type of functionality(mass vhosting from *sql), but i simply don't have enough time to work on this module with my other commitments. -Paul Querna
[PATCH] Use HTTP Accept Filter
This patch changes the default accept filter from "dataready" to "httpready". It will still use "dataready" on FreeBSD before 4.1 (httpready was broken). This change was made in the 1.3 tree before 1.3.23 was released. See: http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_main.c?r1=1.566&r2=1.567&diff_format=h It looks like it just never got pushed up to Apache 2. -Paul Querna Patch Online: http://force-elite.com/~chip/patches/httpd/accept_filter/ Index: server/listen.c === RCS file: /home/cvspublic/httpd-2.0/server/listen.c,v retrieving revision 1.95 diff -u -r1.95 listen.c --- server/listen.c 1 Jan 2004 13:26:23 - 1.95 +++ server/listen.c 3 Feb 2004 17:34:08 - @@ -199,7 +199,13 @@ #if APR_HAS_SO_ACCEPTFILTER #ifndef ACCEPT_FILTER_NAME +#define ACCEPT_FILTER_NAME "httpready" +#ifdef __FreeBSD_version +#if __FreeBSD_version < 411000 /* httpready broken before 4.1.1 */ +#undef ACCEPT_FILTER_NAME #define ACCEPT_FILTER_NAME "dataready" +#endif +#endif #endif apr_socket_accept_filter(s, ACCEPT_FILTER_NAME, ""); #endif signature.asc Description: This is a digitally signed message part
Re: [PATCH] Use HTTP Accept Filter
Forgot the new Patch procedure. Now added to bugzilla as PR 26650: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26650 -Paul Querna On Tue, 2004-02-03 at 10:44, Paul Querna wrote: > This patch changes the default accept filter from "dataready" to > "httpready". It will still use "dataready" on FreeBSD before 4.1 > (httpready was broken). > > This change was made in the 1.3 tree before 1.3.23 was released. > See: > http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_main.c?r1=1.566&r2=1.567&diff_format=h > > It looks like it just never got pushed up to Apache 2. > > -Paul Querna > > Patch Online: > http://force-elite.com/~chip/patches/httpd/accept_filter/ signature.asc Description: This is a digitally signed message part
Add Exception Hooks to 2.0
Exception hooks are awesome. Quite possibly the best thing since sliced bread for module developers! It is difficult to get users to install httpd 2.1, so I would like to see the exception hooks added to the 2.0 branch. mod_backtrace is very helpful for catching problems under high load and other situations where running under GDB is not feasible. mod_backtrace is also no longer Linux specific, It can now work under FreeBSD once 'libexecinfo' is installed from the FreeBSD Ports system. Can we get some binding votes on this? -Paul Querna signature.asc Description: This is a digitally signed message part
Re: apr/apr-util python dependence
> httpd is still just as "buildable" on such platforms regardless of > gen-build.py: from the release tarballs. Building from a CVS checkout > cannot be done without extra tools, but that has always been true in > 2.0: you need libtool and autoconf (not to mention the CVS client). > Hell, autoconf itself has required Perl and GNU m4 for the last > three-odd years. Then the decision is made right there. Apache requires libtool to build from CVS. Libtool Requires Perl. Instead of writing it in Python, do it in Perl. Perl is a higher enough level language and it should be easy to maintain. If you are on a platform without Perl, you won't have libtool anyways. Right? This adds no further dependencies for building Apache from CVS, and allows use of a higher level language. So, why not rewrite it in Perl instead of degrading it into shell crap that is hard to maintain and add features to? This seems like a sensible solution to me. -Paul Querna signature.asc Description: This is a digitally signed message part
Re: FreeBSD 4.x and Apache2: worker MPM issue
On Sat, 2004-02-28 at 23:59, Justin Erenkrantz wrote: > Note that this is fixed on FreeBSD 5.2+ with either libkse or libthr. libc_r, > the default in 5.2, still doesn't work - you have to use libmap.conf, etc. btw, libkse is now the default for -CURRENT, which means for the 5.3 Release end Users will not have to use libmap.conf. Hurrah, libc_r is finally going away! - Paul Querna
Re: FreeBSD 4.x and Apache2: worker MPM issue
On Sat, 2004-03-06 at 18:50, Marc G. Fournier wrote: > Actually, I think it might have been fixed ... On my Jan 6th FreeBSD > server, I am getting weird responses with threading enabled, but two of my > others ones (Jan 23rd nd Feb 4th) both seem to be working consistently ... On my 4.9-STABLE machine built today: FreeBSD tsunami.in.force-elite.com 4.9-STABLE FreeBSD 4.9-STABLE #8: Sun Mar 7 10:49:58 PST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/tsunami i386 The worker MPM built from CVS HEAD as of Today does not work. It still exhibits the broken behavior as Justin has described it. Are you sure your machines are 4.9-STABLE and you are running the worker MPM? Do you have something special in your configuration? -Paul Querna signature.asc Description: This is a digitally signed message part
Re: FreeBSD 4.x and Apache2: worker MPM issue
On Sun, 2004-03-07 at 13:50, Marc G. Fournier wrote: > Now, from the way that Justin explains it, its possible that the hits are > continous enough not to exhibit the problem? How are you testing this? I can do it with just a simple telnet or with Firefox. I don't understand how you can even 'pass' a simple test. What is your configure line? What is httpd linked to? (ldd httpd) I added --enable-nonportable-atomics, but it doesn't make any difference for me. Are you using the Apache 2.0.48 from the FreeBSD Ports? -Paul Querna signature.asc Description: This is a digitally signed message part
Re: 2.0.49 rolled
On Fri, 2004-03-19 at 08:16, Sander Temme wrote: > On the BSD box, when I switch the localhost lines so that IPv4 > (127.0.0.1) comes before IPv6 (::1), and re-run the tests, I see the > server (using netstat) bind to only IPv4. Tests succeed. This sounds like a --disable-v4-mapped issue. http://httpd.apache.org/docs-2.0/bind.html#ipv6 It says this is the behavior default on FreeBSD, NetBSD, and OpenBSD.(Not sure what is going on with your report mentioning Mac OSX). Can you provide the exact Listen directives used in your test? Thanks, Paul Querna signature.asc Description: This is a digitally signed message part
Re: mod_auth_digest and MSIE
On Fri, 2004-03-19 at 16:59, Geoffrey Young wrote: > it probably needs a better name, though :) AuthDigestEnableQueryStringHack is a great name. Its an fugly name for an fugly Hack. I forget who originally suggested the name, but I like it. Geoff, I like your approach in that patch. It keeps that huge if() from getting any bigger or more complicated. -Paul Querna signature.asc Description: This is a digitally signed message part
Change a Module's Configuration, was Re: [apache-modules] How does a module specify the equivalent of AcceptPathInfo On
On Sat, 2004-03-27 at 21:54, Joe Lewis wrote: > Allow me to rephrase that in a way I think you are meaning. You are > trying to use one module to alter the configuration of another module. > It really shouldn't be done. However, anything is possible. Using the > ap_get_module_config in a case where you are grabbing the configuration > of the other module, you are going to have all kinds of linking problems > - if you do it this way, it means you have to redefine the core module. > You can easily get the core module config: #define CORE_PRIVATE #include "http_core.h" core_server_config * conf = (core_server_config *) ap_get_module_config(r->server->module_config, &core_module); conf->accept_path_info = 1; This is a completely evil hack and should never _ever_ be used. I believe the inability to change another module's configuration is a design flaw in Apache 2.0. I am hitting this problem in my mod_vhost_dbi module. My module stores all the information on a virtual host in a database(pgsql, mysql, sqlite, oracle or msql). It is difficult for my module to create a vhost environment on-the-fly and change configuration directives as needed. I am interested in creating a generic API for changing configuration on-the-fly within a running httpd. Todo it right, it might take many large changes. I think there would still be some configuration options that would be marked "init only", but many others could be changed dynamically. The easy way might be to hook into how .htaccess files work. I would want to get a couple people within the httpd-core to support such a change in concept before spending too much time on it. This would be an awesome feature to push into 2.1 or 2.3(if 2.2 is ever released). It opens up a wide variety of possibilities for module developers. -Paul Querna signature.asc Description: This is a digitally signed message part
Re: Proposal: AP_FTYPE_PREPROCESS
On Sun, 2004-04-25 at 19:25, Nick Kew wrote: > Rather than use hacks like AP_FTYPE_RESOURCE-1, would it not be > better to introduce a new output filter type AP_FTYPE_PREPROCESS > below RESOURCE for this kind of application? Originally I didn't think this was good; rather that ordering of filters should be done by the user/coder.(ie add them in the order you want them). After talking to niq on IRC, i realized this is contrary to how filters already operate (why even have connection type filters then? why not have the user apply them in the required order?) It makes sense to add another (or even more) types of filters. This allows for cleaner control of the active filters in addition to making it easier for everyone involved. -Paul Querna signature.asc Description: This is a digitally signed message part
Re: Apache config
On Fri, 2004-04-30 at 04:42, Eli Marmor wrote: > 3. Ability to change any directive, from anywhere in Apache, on-the- >fly. This 'feature' would make doing on-the-fly virtual hosting much much easier. So, what is the next step? Anyone making up some plans? -Paul Querna signature.asc Description: This is a digitally signed message part
Re: is it possible to mark buckets to be copied only when to be set-aside?
On Wed, 2004-05-19 at 07:38 +0100, Nick Kew wrote: > We have at least one implementation that works like that (originally > mine, but now more actively developed by others as "mod_transform"). > Perhaps mod_perl users might benefit from switching? Currently it is only in a Subversion Repo: http://svn.outoforder.cc/svn/mod_transform/trunk/ We were planing on making our first public 'release' version in the next day or so. -Paul Querna signature.asc Description: This is a digitally signed message part
Re: mod_ldap maybe feature request
On Sun, 2004-05-23 at 15:28 -0500, Jess Holle wrote: > Actually the repeated one I hear is: > Can we have a single resource / URL pattern authencticated > against multiple LDAPs (e.g. A, B, C,...) such that if user U > is not defined in A, B will be searched, and so forth. The > first LDAP containing an entry found for the user would be > bound against and determine pass / fail. > As I understand it, this is not currently possible. > This would be an interesting application of the AuthN framework stuff in 2.1.0. It is much easier to setup fallback authentication stuff. Speaking of that, Is there any reason mod_auth_ldap hasn't been moved over to the AuthN/Z Framework? -Paul Querna
Rebuilding modules.apache.org
Greetings, modules.apache.org (MAO) has housed a listing for Apache Modules for several years now. In #apache-modules on Freenode IRC we have had many discussions on how to improve the limited focus of the current MAO website. Our goal is to build a new Apache Modules website using a native Apache Module, and for this module to also serve as an excessively documented example of building an Internet Application with Apache. Our plans for a new site focus on three main audiences: 1) People Searching for a Module 2) People developing Modules 3) People listing their modules for others to find. Finding a Module: This is perhaps the most common visitor to the site. They are browsing for a module to help them accomplish something. The area is somewhat addressed with the existing website, but is very limited with only a simple text search available. Our plans are to include a browsable hierarchical category system, in addition to an expanded text and keyword searching system. Developing Modules: An area of general weakness for HTTPd is the lack of developer documentation. The current website has a few links to mostly outdated documents. We plan to address this audience in two thrusts. First, provide concise tutorials by using simple modules to help people just starting with Apache. This could also include general overviews of the Apache architecture and examples of the various handlers or filters. Secondly, to provide a well documented complete application(the website itself!) as an example of more advanced development and integration. Additionally we would like to have complete and searchable API documentation to help the more experienced developers. Listing Modules: Our goal here is to provide an easy to use interface to let modules authors advertise their modules. The current website does not have centralized accounts, so each module has a separate login. Our plans are to complete redesign this interface to have one account per author and allow many more details of a Module be included in its description. In the future we would also expand this to let other users comment on a module. We have an initial design document that outlines our basic technical architecture: http://svn.outoforder.cc/svn/mod_modules/trunk/docs/design.xml We are looking for feedback on our plans. What do you want to see on a new modules website? What features are important to you? What hurdles do you see to a successfully replacement? What other audiences should we try to address? Thank You, -Paul Querna
Re: [PATCH] event driven MPM
On Tue, 2004-06-08 at 10:23 -0400, Greg Ames wrote:
> Here is the patch - http://apache.org/~gregames/event.patch . It is currently
> based on the worker MPM from 2.1 HEAD to make it easier to review. It is
> working well for me under load on Linux and serves pages on Solaris. When I run
> specweb99 I've seen around 170 connections served by 5 to 20 worker threads.
> This is totally dependent on the time the workload spends in keepalive/user
> think time vs. time spent doing anything else, so YMMV.
Very Neat :D
> This approach could very well hit scalability bottlenecks with various poll()
> implementations as described on Kegel's web site listed above. There are many
> alternatives emerging. I've gotten a few inquiries about using sys_epoll on
> Linux, which sounds like a great fit. I wanted to get something working with
> plain ol' generic (portable) poll() first before trying out any OS dependent
> variations. The current apr_pollset_remove will eventually become a bottleneck
> too -
>
> #ifdef HAVE_POLL
> for (i = 0; i < pollset->nelts; i++) {
> etc
I don't think everyone on this list is aware of this, but I have an
outstanding patch[1] for apr_pollset to add both KQueue and sys_epoll
backends. Hopefully this will get committed soon.
> Other issues are described at http://apache.org/~gregames/event.laundry_list .
> However I think the patch is robust enough now to post. I'm very interested in
> feedback and having people try it out before going further.
Mentioned on that laundry list is adding to the pollset from another
thread. I believe this is supported by both KQueue and sys_epoll. I
guess it could be easily supported with some #ifdefs.
> From: http://apache.org/~gregames/event.laundry_list
> Should new connections be passed to the event_thread to test for
> readability? It's good if there are long delays before the first data
> packet is processed; if there is no delay, it's extra complexity and
> wasted cycles. The thread switches could be minimized if the event
> thread and listener were merged.
I like the general idea, but as a note, FreeBSD has accept filters
which already do some of this. See:
http://www.freebsd.org/cgi/man.cgi?query=accf_http
(It is enabled in the Apache code, but is not commonly enabled in the
FreeBSD kernel. I don't believe Linux has any equivalent)
I think having the Event Thread also handle the Accept() would be the
best method in the long run.
-Paul Querna
[1] - http://marc.theaimsgroup.com/?t=10865022751&r=1&w=2
Accept Filter Backport Request
Back in February I submitted a patch to use the httpready accept filter, and it was committed to 2.1: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/listen.c?r1=1.95&r2=1.96 Pretty simple change, is there any chance someone can start a vote on getting it backported to the 2.0 Branch? Thanks, - Paul Querna
[PATCH] mod_unique_id: Keep running w/ Broken DNS
In #apache on FreeNode IRC, mod_unique_id is one of the most common
problems. Thanks to some distributions (ahem. gentoo.), that commonly
do not configure DNS correctly, and enable mod_unique_id by default,
several times a day people come in saying apache will not start for
them.
I see three ways to solve this issue:
1) Make the error we spit out more verbose when DNS is broken.
2) Continue running, turning off mod_unique_id.
3) Complain to upstream vendors.(don't enable mod_unique_id by default!)
Most of the people with this problem have no reason to be running
mod_unique_id, but their distro has enabled it, so I believe the best
method is to spit out info about it in the error log, but to keep Apache
running.
The attached patch is a quick hack to let mod_unique_id disable itself
if the DNS resolution fails.
No matter what is done, It would be nice to have some sort of change
into 2.0.50 before a release is made.
Thanks,
-Paul Querna
Index: mod_unique_id.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/metadata/mod_unique_id.c,v
retrieving revision 1.50
diff -u -r1.50 mod_unique_id.c
--- mod_unique_id.c 9 Feb 2004 20:29:21 - 1.50
+++ mod_unique_id.c 16 Jun 2004 01:58:37 -
@@ -115,6 +115,8 @@
* htonl/ntohl. Well, this shouldn't be a problem till year 2106.
*/
+static int mod_unique_id_enabled;
+
static unsigned global_in_addr;
static unique_id_rec cur_unique_id;
@@ -165,8 +167,9 @@
*/
if ((rv = apr_gethostname(str, sizeof(str) - 1, p)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ALERT, rv, main_server,
- "mod_unique_id: unable to find hostname of the server");
-return HTTP_INTERNAL_SERVER_ERROR;
+ "mod_unique_id: unable to find hostname of the server. mod_unique_id is now disabled.");
+mod_unique_id_enabled = 0;
+return OK;
}
if ((rv = apr_sockaddr_info_get(&sockaddr, str, AF_INET, 0, 0, p)) == APR_SUCCESS) {
@@ -184,9 +187,13 @@
"mod_unique_id: using low-order bits of IPv6 address "
"as if they were unique");
}
-else
+else {
+#endif
+mod_unique_id_enabled = 0;
+return OK;
+#if APR_HAVE_IPV6
+}
#endif
-return HTTP_INTERNAL_SERVER_ERROR;
}
apr_sockaddr_ip_get(&ipaddrstr, sockaddr);
@@ -208,6 +215,7 @@
* next second.
*/
apr_sleep(apr_time_from_sec(1) - apr_time_usec(apr_time_now()));
+mod_unique_id_enabled = 1;
return OK;
}
@@ -216,6 +224,8 @@
pid_t pid;
apr_time_t tv;
+if(mod_unique_id_enabled == 0)
+return;
/*
* Note that we use the pid because it's possible that on the same
* physical machine there are multiple servers (i.e. using Listen). But
@@ -290,6 +300,10 @@
unsigned short counter;
const char *e;
int i,j,k;
+
+if(mod_unique_id_enabled == 0) {
+return DECLINED;
+}
/* copy the unique_id if this is an internal redirect (we're never
* actually called for sub requests, so we don't need to test for
Dumping Loaded Modules
Attached is patch add a new command line option to httpd:
'-t -D DUMP_MODULES'
This will print a list of all loaded shared modules and all statically
compiled modules.
My only question is, what should the command be called?
'-t -D DUMP_MODULES' vs '-M' vs some other argument.
I based DUMP_MODULES on the existing DUMP_VHOSTS command, but I am not
sure if the DUMP_VHOSTS is supposed to be a standard or not?
-Paul Querna
Index: modules/mappers/mod_so.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_so.c,v
retrieving revision 1.57
diff -u -r1.57 mod_so.c
--- modules/mappers/mod_so.c 4 Jun 2004 22:40:46 - 1.57
+++ modules/mappers/mod_so.c 20 Jun 2004 01:35:44 -
@@ -347,6 +347,39 @@
return NULL;
}
+static void ap_dump_loaded_modules(apr_pool_t* p, server_rec* s)
+{
+ap_module_symbol_t *modie;
+ap_module_symbol_t *modi;
+so_server_conf *sconf;
+module *modp;
+int i;
+apr_file_t *out = NULL;
+apr_file_open_stderr(&out, p);
+
+apr_file_printf(out, "Available Modules:\n");
+
+sconf = (so_server_conf *)ap_get_module_config(s->module_config,
+ &so_module);
+for (i = 0; ; i++) {
+modi = &ap_prelinked_module_symbols[i];
+if (modi->name != NULL) {
+apr_file_printf(out, " %s (static)\n", modi->name);
+}
+else {
+break;
+}
+}
+
+modie = (ap_module_symbol_t *)sconf->loaded_modules->elts;
+for (i = 0; i < sconf->loaded_modules->nelts; i++) {
+modi = &modie[i];
+if (modi->name != NULL) {
+apr_file_printf(out, " %s (shared)\n", modi->name);
+}
+}
+}
+
#else /* not NO_DLOPEN */
static const char *load_file(cmd_parms *cmd, void *dummy, const char *filename)
@@ -370,6 +403,7 @@
{
#ifndef NO_DLOPEN
APR_REGISTER_OPTIONAL_FN(ap_find_loaded_module_symbol);
+APR_REGISTER_OPTIONAL_FN(ap_dump_loaded_modules);
#endif
}
Index: modules/mappers/mod_so.h
===
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_so.h,v
retrieving revision 1.1
diff -u -r1.1 mod_so.h
--- modules/mappers/mod_so.h 4 Jun 2004 22:40:47 - 1.1
+++ modules/mappers/mod_so.h 20 Jun 2004 01:35:44 -
@@ -22,6 +22,8 @@
/* optional function declaration */
APR_DECLARE_OPTIONAL_FN(module *, ap_find_loaded_module_symbol,
(server_rec *s, const char *modname));
+APR_DECLARE_OPTIONAL_FN(void, ap_dump_loaded_modules,
+(apr_pool_t* p, server_rec *s));
#endif /* MOD_SO_H */
Index: server/main.c
===
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.157
diff -u -r1.157 main.c
--- server/main.c 25 Apr 2004 17:23:31 - 1.157
+++ server/main.c 20 Jun 2004 01:35:49 -
@@ -36,6 +36,8 @@
#include "ap_mpm.h"
#include "mpm_common.h"
+#include "mod_so.h" /* for dumping loaded modules */
+
/* WARNING: Win32 binds http_main.c dynamically to the server. Please place
* extern functions and global data in another appropriate module.
*
@@ -319,75 +321,77 @@
#ifdef SHARED_CORE
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- " -R directory : specify an alternate location for "
+ " -R directory : specify an alternate location for "
"shared object files");
#endif
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- " -D name : define a name for use in "
+ " -D name: define a name for use in "
" directives");
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- " -d directory : specify an alternate initial "
+ " -d directory : specify an alternate initial "
"ServerRoot");
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- " -f file : specify an alternate ServerConfigFile");
+ " -f file: specify an alternate ServerConfigFile");
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- " -C \"directive\": process directive before reading "
+ " -C \"directive\" : process directive before reading "
"config files");
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- " -c \"directive\": process directive after reading "
+ " -c \"directive\" : proce
Re: modules.apache.org sold my e-mail address to spammers
On Sun, 2004-06-20 at 20:22 -0700, Matthew Lloyd wrote: > Dear Apache community, > > I submitted a module to modules.apache.org (mod_log_firstbyte) a month or > two ago. When I filled in the form, I supplied a *unique* e-mail address > that I have *not* used *anywere* else - [EMAIL PROTECTED] > > 1) This e-mail address is now receiving spam. There is only one way this can > have happened. The folks who run modules.apache.org must have sold my > address to a spammer. I am 99% sure that did not happen. My best guess is that a spammer is harvesting the 'apache-modules-announce' email list. > 2) I have never been able to log in to update my module and when asking for > a replacement password I have never received a reply from [EMAIL PROTECTED] I don't think the people at Covalent are actively taking care of the Modules Website. :( > I think you all need to be warned of this - it's a disgrace that this site > is a subdomain of apache.org! Something needs to be done... Yes yes, as a separate issue, It needs to be updated/redone, its on my TODO, and I have sent out request for comments on a new design, but only received one reply. -Paul Querna
Re: Dumping Loaded Modules
On Sun, 2004-06-20 at 20:34 -0400, Geoffrey Young wrote: > > Index: modules/mappers/mod_so.h > > === > > RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_so.h,v > > retrieving revision 1.1 > > diff -u -r1.1 mod_so.h > > --- modules/mappers/mod_so.h4 Jun 2004 22:40:47 - 1.1 > > +++ modules/mappers/mod_so.h20 Jun 2004 01:35:44 - > > @@ -22,6 +22,8 @@ > > /* optional function declaration */ > > APR_DECLARE_OPTIONAL_FN(module *, ap_find_loaded_module_symbol, > > (server_rec *s, const char *modname)); > > +APR_DECLARE_OPTIONAL_FN(void, ap_dump_loaded_modules, > > +(apr_pool_t* p, server_rec *s)); > > out of curiosity, what is the advantage to using the optional function here? > I am only familiar with it in the mod_include sense, so perhaps I should be > looking into something like this instead? The reason it is an optional function is that mod_so is not always statically compiled into apache. This is an easy way to avoid a bunch of #defines in main.c trying to tell if mod_so is statically linked in to httpd. -Paul Querna
Re: IfModule symbol extension Backport request (PR: 29003)
On Tue, 2004-06-22 at 08:34 +0200, Andrà Malo wrote: > * Edward Rudd <[EMAIL PROTECTED]> wrote: > > > I just applied this patch to the Apache_20_branch and the code applies, > > compiles, and runs cleanly (only tested on linux RH 7.3). I'm puttingthis > > up for a vote to be applied from cvs head to the 2.0 branch. > > I'm -1 on it, sorry. > We should not try to backport all stuff, just because we can. 2.0 is *stable*. > So the only things that are backported, should be bug fixes or important/not > workaroundable features. > I'm considering the extension just as a new feature. For 2.1. > I actually asked Eddie about the possibility to get this into 2.0, as my DUMP_MODULES stuff relies upon his IfModule Changes. I see your point nd, but it would be nice if I knew when these cool features would make it into any stable branch. (ie a 2.2 ROADMAP...) -Paul Querna
buildconf on CVS Snapshots
Is it possible to have buildconf be run on the server when the CVS Snapshots are made of httpd-2.0? This is a common practice for open source projects with their CVS snapshots, and removes extra dependencies on autofoo for users. Thanks, -Paul Querna
Re: buildconf on CVS Snapshots
On Wed, 2004-06-23 at 20:18 -0700, Sander Temme wrote: > On Jun 23, 2004, at 6:17 PM, Paul Querna wrote: > > > Is it possible to have buildconf be run on the server when the CVS > > Snapshots are made of httpd-2.0? > > > > This is a common practice for open source projects with their CVS > > snapshots, and removes extra dependencies on autofoo for users. > > The problem with that, for us, is that the CVS server machine runs > FreeBSD and has GNU libtool installed from the ports collection. The > FreeBSD ports collection has a really old version of libtool (1.3.4), > which is broken for many platforms. Try /usr/ports/devel/libtool14 I use it on serveral FreeBSD machines for Apache and Module Development, without any problems. > An option would be to install an > autotoolset of the level that we require/like, say in /usr/local/gnu, > and prepend its bin to the PATH for roll operations. That would give us > a known autotoolset for releases/drops instead of what the RM happens > to have on their machine. I like that better. Give a very controlled environment for making releases, so that they are all consistent. -Paul Querna
2.2 Roadmap?
I believe it is time to look seriously at what would compose a 2.2 Stable Branch. There have been various threads in the past saying a 2.2 stable branch is not far off, and with the impending of release of APR- 1.0, we should turn our attention to HTTPd. While searching for something else, I found this interesting quote from 2002: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06365.html On Tue, 2002-02-26 at 11:26, Dale Ghent wrote: ...snip... > There's no roadmap; There's no release date of any sort for the tree, > be it alpha, beta, delta, zulu, red, yellow, or final. No code > regression testing. > > I kind of get the feeling that someone will wake up one morning and say > "Hey, let's release 2.0!" and I fear that. Then the scramble To Get Stuff > In ensues. While I don't think the situation is that bad yet, there is a serious lack of direction for the 2.1 branch. The Roadmap is completely outdated; it was last updated 19 months ago. The 2.0 branch was made over 18 months ago, it is time to make another stable branch. I believe many people want the AAA changes, and it brings even more features to encourage people to upgrade from 1.3. To better facilitate this, I would like to rewrite the ROADMAP with specific goals for what will make up a 2.2 Stable Branch. Lets make a list of things that *must* be in 2.2, so we know when we reach our goals. Otherwise as Dale wrote in 2002, one morning someone will wake up and say "Hey, let's release 2.2!". This is only a list from my initial thoughts, please comment and make suggestions. I will take the resulting thread and rewrite the ROADMAP file. *** Outstanding Issues *** - Show Stoppers in STATUS: - Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2 - the edge connection filter cannot be removed http://marc. theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2 - LDAP Authentication - Needs to use the AuthN/Z framework - Caching Code needs Stabilization or Removal(see AAA Cache) - mod_cache - STATUS says it still violates RFCs. Whats going on? Is anyone fixing it? - All Experimental Modules: Improve it or loose it. - Make Worker the Default MPM on for threaded Unix boxes? - Vote in STATUS says this should already be done. - Document any API Changes for Module Authors. - We want to make this an 'easy' upgrade. - Most of the work IMHO is APR 0.9 -> 1.0 - Make _private.h files for all functions that are not part of the public API. *** Borderline Issues *** - mod_zeroconf - Offered for donation. Status? - Event Driven MPM - Greg Ames has a patch to add this. Needs stabilization, testing, and performance improvements. I would like to see it in 2.2, but I don't know how much time Greg has. - AAA Cache Framework - Caching Method for all AuthN/Z backends would be nice - Possible todo this *without* API Changes.(Could be done once 2.2 is stable) *** Issues for 2.3.0-dev *** - Replace the Perchild MPM with a different/working model. - Allow Arbitrary File Backends. This is only my initial list, please comment and add more. -Paul Querna
Re: 2.0.50 tarballs available for testing
On Tue, 2004-06-29 at 02:27 +0200, Sander Striker wrote: > Please test and cast your votes for release. Good On FreeBSD 5.2.1
Re: cvs commit: httpd-2.0/server config.c core.c request.c
On Wed, 2004-07-14 at 09:01 +0200, Andrà Malo wrote: > * [EMAIL PROTECTED] wrote: > > > Modified:.CHANGES > >docs/manual/mod core.xml > >include http_config.h http_core.h httpd.h > >server config.c core.c request.c > > Log: > > Added 'AllowOverride Options=Indexes,MultiViews' to give an admin better > > control over what options can be used in .htaccess files. > > Please do not use tabs (just four spaces for indentation). > Fixed.
[PATCH] pollset_poll() improvements
The attached patch removes the double for() loops in both the KQueue
and epoll _poll() implementations. Both epoll and kqueue have a method
for associating arbitrary user data with the event. This patch uses
these to store the key to an event's location in the query_set array.
I also had to change testpoll.c again because the kqueue and epoll
implementations will return their result set with a different order (but
the same sockets will still come..)
Thanks,
-Paul Querna
Index: poll/unix/poll.c
===
RCS file: /home/cvspublic/apr/poll/unix/poll.c,v
retrieving revision 1.46
diff -u -r1.46 poll.c
--- poll/unix/poll.c 7 Jul 2004 07:40:12 - 1.46
+++ poll/unix/poll.c 18 Jul 2004 21:30:31 -
@@ -471,7 +471,8 @@
}
if (descriptor->reqevents & APR_POLLIN) {
-EV_SET(&pollset->kevent, fd, EVFILT_READ, EV_ADD, 0, 0, NULL);
+EV_SET(&pollset->kevent, fd, EVFILT_READ, EV_ADD, 0, 0,
+(void*)pollset->nelts);
if (kevent(pollset->kqueue_fd, &pollset->kevent, 1, NULL, 0,
NULL) == -1) {
@@ -480,7 +481,8 @@
}
if (descriptor->reqevents & APR_POLLOUT) {
-EV_SET(&pollset->kevent, fd, EVFILT_WRITE, EV_ADD, 0, 0, NULL);
+EV_SET(&pollset->kevent, fd, EVFILT_WRITE, EV_ADD, 0, 0,
+(void*)pollset->nelts);
if (kevent(pollset->kqueue_fd, &pollset->kevent, 1, NULL, 0,
NULL) == -1) {
@@ -490,16 +492,16 @@
#elif defined(HAVE_EPOLL)
ev.events = get_epoll_event(descriptor->reqevents);
+ev.data.fd = pollset->nelts;
if (descriptor->desc_type == APR_POLL_SOCKET) {
-ev.data.fd = descriptor->desc.s->socketdes;
ret = epoll_ctl(pollset->epoll_fd, EPOLL_CTL_ADD,
descriptor->desc.s->socketdes, &ev);
}
else {
-ev.data.fd = descriptor->desc.f->filedes;
ret = epoll_ctl(pollset->epoll_fd, EPOLL_CTL_ADD,
descriptor->desc.f->filedes, &ev);
}
+
if (0 != ret) {
return APR_EBADF;
}
@@ -723,14 +725,15 @@
return APR_NOTFOUND;
}
+
#ifdef HAVE_KQUEUE
+
APR_DECLARE(apr_status_t) apr_pollset_poll(apr_pollset_t *pollset,
apr_interval_time_t timeout,
apr_int32_t *num,
const apr_pollfd_t **descriptors)
{
-int rv;
-apr_uint32_t i, j, r = 0;
+int rv, i, r;
struct timespec tv, *tvptr;
if (timeout < 0) {
@@ -752,28 +755,16 @@
return APR_TIMEUP;
}
-/* TODO: Is there a better way to re-associate our data? */
-for (i = 0; i < pollset->nelts; i++) {
-apr_os_sock_t fd;
-if (pollset->query_set[i].desc_type == APR_POLL_SOCKET) {
-fd = pollset->query_set[i].desc.s->socketdes;
-}
-else {
-fd = pollset->query_set[i].desc.f->filedes;
-}
-for (j = 0; j < rv; j++) {
-if (pollset->ke_set[j].ident == fd ) {
-pollset->result_set[r] = pollset->query_set[i];
-pollset->result_set[r].rtnevents =
-get_kqueue_revent(pollset->ke_set[j].filter,
- pollset->ke_set[j].flags);
-r++;
-}
-}
+r = 0;
+for (i = 0; i < rv; i++) {
+pollset->result_set[r] =
+pollset->query_set[((int)pollset->ke_set[i].udata)];
+pollset->result_set[r].rtnevents =
+get_kqueue_revent(pollset->ke_set[i].filter,
+ pollset->ke_set[i].flags);
+r++;
}
-(*num) = r;
-
if (descriptors) {
*descriptors = pollset->result_set;
}
@@ -788,8 +779,7 @@
apr_int32_t *num,
const apr_pollfd_t **descriptors)
{
-int rv;
-apr_uint32_t i, j, k;
+int rv, i, r;
if (timeout > 0) {
timeout /= 1000;
@@ -804,38 +794,24 @@
if (rv == 0) {
return APR_TIMEUP;
}
-j = 0;
-for (i = 0; i < pollset->nelts; i++) {
-if (pollset->pollset[i].events != 0) {
-/* TODO: Is there a better way to re-associate our data? */
-for (k = 0; k < pollset->nelts; k++) {
-if (pollset->query_set[k].desc_type == APR_POLL_SOCKET &&
-pollset->query_set[k].desc.s->socketdes ==
-pollset->pollset[i].data.fd) {
-pollset->result_set[j] = pollset->query_set[k];
-pollset->result_set[j].rtnevents =
-
Re: [PATCH] pollset_poll() improvements
Sorry, this was intended for apr-dev, I sent it here on accident :) On Sun, 2004-07-18 at 14:36 -0700, Paul Querna wrote: > The attached patch removes the double for() loops in both the KQueue > and epoll _poll() implementations. Both epoll and kqueue have a method > for associating arbitrary user data with the event. This patch uses > these to store the key to an event's location in the query_set array. > > I also had to change testpoll.c again because the kqueue and epoll > implementations will return their result set with a different order (but > the same sockets will still come..) > > Thanks, > > -Paul Querna >
Re: [PATCH] event driven MPM
On Tue, 2004-08-03 at 08:18 -0400, Brian Akins wrote: > Greg Ames wrote: > > Bill Stoddard created an event driven socket I/O patch a couple of > > years ago that could serve pages. I picked it up and decided to see > > if I could simplify it to minimize the changes to request processing. > > What's the status of this? I'd be willing to help if needed. We are > interested in this. > I am interested in it too. I talked to Greg Ames a week ago, and he doesn't have any updates for the patch. I planned on mailing this list about it later this week. I would like to get the patch(or something based off of it) into CVS soon. My basic question for the list is, are we better off modifying the Worker MPM, or should we create a new 'event' MPM for now? -Paul Querna
Re: cvs commit: httpd-2.0/modules/aaa mod_auth_digest.c
On Tue, 2004-08-03 at 15:22 -0400, Geoffrey Young wrote: > hmm, I guess this fell off the collective radar. > > any comments? otherwise, I guess it's good enough and I'll just commit it > to both 2.0 and 2.1. Looks good to me. -Paul Querna > Geoffrey Young wrote: > > > > [EMAIL PROTECTED] wrote: > > > >>pquerna 2004/07/10 00:47:23 > >> > >> Modified:.Tag: APACHE_2_0_BRANCH CHANGES STATUS > >> modules/aaa Tag: APACHE_2_0_BRANCH mod_auth_digest.c > >> Log: > >> Backport of AuthDigestEnableQueryStringHack > >> Needs a doc update to explain what it does. > > > > > > something like the attached? corrections, tweaks, or other feedback welcome. > > > > --Geoff > > > > > > > > > > > > Index: mod_auth_digest.xml > > === > > RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_auth_digest.xml,v > > retrieving revision 1.5.2.8 > > diff -u -r1.5.2.8 mod_auth_digest.xml > > --- mod_auth_digest.xml 17 Apr 2004 18:43:37 - 1.5.2.8 > > +++ mod_auth_digest.xml 12 Jul 2004 14:16:11 - > > @@ -72,7 +72,9 @@ > > browsers. As of November 2002, the major browsers that support digest > > authentication are http://www.opera.com/";>Opera, > href="http://www.microsoft.com/windows/ie/";>MS Internet > > -Explorer (fails when used with a query string), > +Explorer (fails when used with a query string - see the > > +AuthDigestEnableQueryStringHack > > + option below for a workaround), > href="http://www.w3.org/Amaya/";>Amaya, > href="http://www.mozilla.org";>Mozilla and > href="http://channels.netscape.com/ns/browsers/download.jsp"; > > @@ -81,6 +83,36 @@ > > in controlled environments. > > > > > > + > > +Working with MS Internet Explorer > > +The Digest authentication implementation in current Internet > > +Explorer implementations has known issues, namely that > > +requests with a query string are not RFC compliant. There are a > > +few ways to work around this issue. > > + > > + > > +The first way is to use POST requests instead of > > +GET requests to pass data to your program. This method > > +is the simplest approach if your application can work with this > > +limitation. > > + > > + > > +Apache also provides a workaround in the > > +AuthDigestEnableQueryStringHack environment variable. > > +If AuthDigestEnableQueryStringHack is true for the > > +request, Apache will take steps to work around the MSIE bug and > > +remove the request URI from the digest comparison. Using this > > +method would look like similar to the following. > > + > > +Using Digest Authentication with MSIE: > > +BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On > > + > > + > > +See the BrowserMatch > > +directive for more details on conditionally setting environment > > +variables > > + > > + > > > > > > AuthDigestFile
Re: mod_dir and mod_cache
On Tue, 2004-08-03 at 22:29 -0400, Bill Stoddard wrote: > mod_cache, mod_mem_cache and mod_disk_cache are experimental modules > in 2.0, so I am going to bypass the votes > and just start backporting fixes. Please review as they go in. If > something breaks, we'll fix it. Mmmm K? > Whoa. I thought the 2.0 branch was *always* Review first. Back porting these changes does not seem right without proper votes. The LDAP modules are also 'experimental' modules, and they have been using votes for all of their back ports. -Paul Querna
Re: ARM4 module for Apache 2, any interest?
So, after a quick look at the website, it looks like ARM4 is some sort of SNMP on Steroids? Also, the License is quite important for any possibility of donating any module to the ASF I think that needs to be pinned down before any discussion can really move forward. Finally, can you explain what the ARM4 Module does in Apache 2? It just exposes Apache to the ARM4 management tools? Performance Stats? Makes ASCII Art of Gnomes? I need some more details before I even want to read the source code. -Paul Querna On Wed, 2004-08-11 at 12:29 -0400, Bill Stoddard wrote: > I've written a module to ARM4 instrument Apache 2. I'd like to donate this module to > the ASF and ideally put > it in the modules/experimental directory (or somewhere else in the ASF where we can > place it under cvs > control?). The ARM4 API headers are available from the Open Group website at > http://www.opengroup.org/tech/management/arm/ (I have not checked the license > lately. My assumption is that > the license is not too restrictive, though I could be wrong). I've heard rumors that > HP may be making an ARM4 > SDK publically available "real soon now". > > I would sign on to support the module if we put it in httpd-2.0 > modules/experimental. Anyone interested? > > Bill > >
Re: [PATCH] add test_config hook
On Wed, 2004-08-11 at 16:24 +0100, Joe Orton wrote:
> Any interest in this for HEAD? Patch below adds a test_config hook
> which allows modules to do extra checking when httpd is invoked with -t.
> The new "-t -D DUMP_MODULES" feature can be implemented this way rather
> than hooking into mod_so from server/main.c, which I think is slightly
> cleaner; it's useful for other modules too.
Yes, I wrote the Dump Modules stuff, and I like your method better. It
is *much* cleaner.
If there aren't any objections, I will commit this in a couple days.
-Paul Querna
> Index: server/config.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/config.c,v
> retrieving revision 1.180
> diff -u -r1.180 config.c
> --- server/config.c 16 Jul 2004 20:30:43 - 1.180
> +++ server/config.c 11 Aug 2004 15:22:03 -
> @@ -72,6 +72,7 @@
> APR_HOOK_LINK(handler)
> APR_HOOK_LINK(quick_handler)
> APR_HOOK_LINK(optional_fn_retrieve)
> + APR_HOOK_LINK(test_config)
> )
>
> AP_IMPLEMENT_HOOK_RUN_ALL(int, header_parser,
> @@ -81,6 +82,10 @@
>(apr_pool_t *pconf, apr_pool_t *plog,
> apr_pool_t *ptemp),
>(pconf, plog, ptemp), OK, DECLINED)
> +
> +AP_IMPLEMENT_HOOK_VOID(test_config,
> + (apr_pool_t *pconf, server_rec *s),
> + (pconf, s))
>
> AP_IMPLEMENT_HOOK_RUN_ALL(int, post_config,
>(apr_pool_t *pconf, apr_pool_t *plog,
> Index: server/main.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/main.c,v
> retrieving revision 1.161
> diff -u -r1.161 main.c
> --- server/main.c 12 Jul 2004 16:36:42 - 1.161
> +++ server/main.c 11 Aug 2004 15:22:03 -
> @@ -37,8 +37,6 @@
> #include "ap_mpm.h"
> #include "mpm_common.h"
>
> -#include "mod_so.h" /* for dumping loaded modules */
> -
> /* WARNING: Win32 binds http_main.c dynamically to the server. Please place
> * extern functions and global data in another appropriate module.
> *
> @@ -609,18 +607,12 @@
> rv = ap_process_config_tree(server_conf, ap_conftree,
> process->pconf, ptemp);
> if (rv == OK) {
> -APR_OPTIONAL_FN_TYPE(ap_dump_loaded_modules) *dump_modules =
> -APR_RETRIEVE_OPTIONAL_FN(ap_dump_loaded_modules);
> -
> ap_fixup_virtual_hosts(pconf, server_conf);
> ap_fini_vhost_config(pconf, server_conf);
> apr_hook_sort_all();
>
> -if (dump_modules && ap_exists_config_define("DUMP_MODULES")) {
> -dump_modules(pconf, server_conf);
> -}
> -
> if (configtestonly) {
> +ap_run_test_config(pconf, server_conf);
> ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL, "Syntax OK");
> destroy_and_exit_process(process, 0);
> }
> Index: include/http_config.h
> ===
> RCS file: /home/cvs/httpd-2.0/include/http_config.h,v
> retrieving revision 1.111
> diff -u -r1.111 http_config.h
> --- include/http_config.h 14 Jul 2004 06:36:41 - 1.111
> +++ include/http_config.h 11 Aug 2004 15:22:04 -
> @@ -967,6 +967,13 @@
> AP_DECLARE_HOOK(int,pre_config,(apr_pool_t *pconf,apr_pool_t *plog,
> apr_pool_t *ptemp))
>
> +/**
> + * Run the test_config function for each module; this hook is run
> + * only if the server was invoked to test the configuration syntax.
> + * @param pconf The config pool
> + * @param s The list of server_recs
> + */
> +AP_DECLARE_HOOK(void,test_config,(apr_pool_t *pconf, server_rec *s))
>
> /**
> * Run the post_config function for each module
> Index: modules/mappers/mod_so.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_so.c,v
> retrieving revision 1.59
> diff -u -r1.59 mod_so.c
> --- modules/mappers/mod_so.c 12 Jul 2004 16:36:42 - 1.59
> +++ modules/mappers/mod_so.c 11 Aug 2004 15:22:04 -
> @@ -347,13 +347,18 @@
> return NULL;
> }
>
> -static void ap_dump_loaded_modules(apr_pool_t* p, server_rec* s)
> +static void dump_loaded_modules(apr_pool_t* p, server_rec* s)
> {
> ap_module_symbol_t *modie;
> ap_module_symbol_t *modi;
> so_server_conf *sconf;
> int i;
> apr_file_t *out = NULL;
> +
> +if (!ap
Re: ARM4 module for Apache 2, any interest?
On Wed, 2004-08-11 at 12:08 -0500, William A. Rowe, Jr. wrote: [..snip..] > -1 on experimental - it needs to die :) Look how long it's taken to get cache > stable. If that module was only placed in the main distro once it was fully > complete, it would have been finished far sooner. In general, new modules > into 2.0 doesn't seem to make alot of sense since 2.2 will release before > ApacheCon (straightforward goal, don't you think?.) I hope so, but at the pace APR 1.0 is going > One thought on 2.2 was to simply not place any unfinished modules on that > branch, and let them live on in the 2.1-dev (well, that becomes 2.3-dev once > 2.2.0 is golden), until it can be released. The modules can live in the "right > location" in a 2.odd-dev tree from their inception. +1 to that. It makes sense to not include 'experimental' modules that just cause more trouble than they are worth in a GA release. -Paul Querna
Re: AddOutputFilterByType oddness
Is your DefaultType set to text/html? On Tue, 2004-08-24 at 01:54 +0200, Graham Leggett wrote: > Hi all, > > I have just set up the most recent httpd v2.0.51-dev tree, and have > configured a filter that strips leading whitespace from HTML: > > AddOutputFilterByType STRIP text/html > > The content is served by mod_proxy. > > This seems to work fine for HTML requests, but I have noticed that this > filter is also being applied to images as well (thus corrupting them). > Why would the above directive apply to all content, instead of text/html > only as is configured? > > Looking at the following docs: > > http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype > > it says that filters are not applied by proxied requests (It does not > give a reason why not). From the test above however this statement is > false, filters are applied to proxy requests - all proxied requests. > > Am I doing something wrong, or is AddOutputFilterByType broken? > > Regards, > Graham > --
Re: Bugzilla Requests
On Mon, 2004-08-30 at 22:42 -0400, Joshua Slive wrote: > Thinking about this a little more... > > >> 2) Add More Components to Bugzilla. Here is my list of components I > >> would like to see added for our Project: > >> - Windows Installer > >> - Windows Build > > Are these really necessary? We have a "build" category already, and we > could have a similar "install" category. Then you could look in the OS > field to see if it was for windows. (Not quite as convenient, but much > cleaner than duplicating a bunch of stuff across differents OSes.) > The do not use the same systems at all. I guess you have a good enough case for "build", but the installer really needs its own catagory, since windows is the only platform where we provide a binary installer... > >> - Default Configuration (Lots of requests for Add XXX Language or > >> comment out in the Default httpd.conf) > > We already have a "Runtime Config" category which is meant for exactly > this. Perhaps it is not used as much as it should be. > I think they should be different. Runtime != Defaults
Removing the Experimental MPMs in 2.2?
Do we want to include the experimental MPMs in the 2.2 GA Branch?
Currently the MPMs in server/mpm/experimental are:
- leader
- perchild
- threadpool
I hope to add the 'event' MPM to this list soon, but I have been
distracted rewriting apr_pollset to better work with multiple threads.
(IE making pollset_{add(),remove()} threadsafe...)
My personal feeling is to *not* include them in the 2.2 branch at this
time. If any of the experimental MPMs are improved to a state we feel
they can be tested, then lets put them back in the GA branch, in the
experimental directory. If after more testing in the GA branch they
prove stable, we can then take them out of experimental.
Using perchild as an example, many users see that it is available in 2.0
and try it out. They then complain and make silly posts on Slashdot when
it doesn't work. Why include these MPMs if no one is actively working on
or supporting them? It doesn't make sense for the 'Stable Branch' to
include them at all.
Any other opinions about not including these MPMs?
-Paul Querna
Re: Removing the Experimental MPMs in 2.2?
On Fri, 2004-09-03 at 18:12 +0200, Matthieu Estrade wrote: > Considering some experimental stuff is sometimes stable on some > plateform and still experimental because unstable on others, it could be > better to keep them in, just for users who want to try and help. If > these modules are deleted, some people will refuse to upgrade because > they will not find features they need (ex cache or ldap)... > I was only talking about the MPMs, not the other experimental Modules. (cache, ldap, etc). These modules are a separate subject. I believe ldap has already been moved out of experimental in 2.1, and mod_cache is going to move out too. -Paul
Re: Removing the Experimental MPMs in 2.2?
On Fri, 2004-09-03 at 09:55 -0400, Jim Jagielski wrote: > I'm not sure what you mean... I think that, at the source > code level, all experimental modules (whether MPMs or > not) should be included (but not *built* when doing > packages). I guess I wasn't clear. I would like to keep all of our experimental MPMs in the 2.3 development/CVS HEAD tree. I would like to *not* include them in the 2.2 'stable' general availability branch. > After all, the hope is that people try them > out and provide fixes, patches, etc... I don't think this has happened recently at all. Just look at perchild, or any of the other experimental MPMs in the 2.0 Branch. People are not providing patches for them. -Paul Querna
Re: Removing the Experimental MPMs in 2.2?
On Fri, 2004-09-03 at 18:47 +0200, Enrico Weigelt wrote: > * Florian Lindner <[EMAIL PROTECTED]> wrote: > > Hi folks, > > > > Maybe replacing perchild with metuxmpm would be a good idea? metuxmpm does > > basically the same, but in fact it works. > > ACK. > We'd be glad to get it in the official tree. Have a patch against 2.1/cvs that I can review?
Re: cvs commit: httpd-2.0/modules/generators mod_info.c
On Fri, 2004-09-03 at 16:06 -0700, Roy T. Fielding wrote:
> -0.9. This change needs review. The coding style should stick to
> the httpd guidelines.
Yes, but I did not commit a correct style patch, because that would of
been *impossible* to review. The style of mod_info does not follow the
guidelines, and Rici's original patch was much larger (including style
fixes). My plan was to make his functional changes first, and come back
later this weekend for a style cleanup of mod_info.
> Also, we don't add comments to a credit log inside the file
> (instead of just CHANGES), and whether or not God intended
> recursion is not relevant (though that part of the changes
> does look good).
What is the Policy on this? Should we remove the old ones from existing
files? Sort of like how @author tags have been removed from other ASF
projects...
> It is unfortunate that the diff gets confused about the new functions
> and treats them as changes -- it makes review a pain in the butt.
Like I said, this is the minimal patch to get the functional differences
for mod_info. mod_info already did not fit the style guide, and making
Functional and Style changes in the same commit is even harder to
review.
> Roy
>
>
> On Sep 2, 2004, at 7:31 PM, [EMAIL PROTECTED] wrote:
>
> > pquerna 2004/09/02 19:31:06
> >
> > Modified:.CHANGES
> >modules/generators mod_info.c
> > Log:
> > Rewrote config tree walk using recursion the way God intended.
> > Added ?config option. Added printout of config filename and line
> > numbers.
> >
> > PR: 30919
> > Submitted by: Rici Lake
> >
> > Revision ChangesPath
> > 1.1584+4 -0 httpd-2.0/CHANGES
> >
> > Index: CHANGES
> > ===
> > RCS file: /home/cvs/httpd-2.0/CHANGES,v
> > retrieving revision 1.1583
> > retrieving revision 1.1584
> > diff -u -r1.1583 -r1.1584
> > --- CHANGES 2 Sep 2004 19:49:19 - 1.1583
> > +++ CHANGES 3 Sep 2004 02:31:05 - 1.1584
> > @@ -2,6 +2,10 @@
> >
> > [Remove entries to the current 2.0 section below, when backported]
> >
> > + *) mod_info: Rewrote config tree walk using a recursive function.
> > + Added ?config option. Added printout of config filename and
> > line numbers.
> > + [Rici Lake , Paul Querna]
> > +
> > *) mod_proxy: Fix type error that prevents proxy-sendchunks from
> > working.
> > [Justin Erenkrantz]
> >
> >
> >
> >
> > 1.57 +98 -95httpd-2.0/modules/generators/mod_info.c
> >
> > Index: mod_info.c
> > ===
> > RCS file: /home/cvs/httpd-2.0/modules/generators/mod_info.c,v
> > retrieving revision 1.56
> > retrieving revision 1.57
> > diff -u -r1.56 -r1.57
> > --- mod_info.c9 Feb 2004 20:29:19 - 1.56
> > +++ mod_info.c3 Sep 2004 02:31:06 - 1.57
> > @@ -25,6 +25,7 @@
> > * GET /server-info?server - Returns server configuration only
> > * GET /server-info?module_name - Returns configuration for a
> > single module
> > * GET /server-info?list - Returns quick list of included modules
> > + * GET /server-info?config - Returns full configuration
> > *
> > * Rasmus Lerdorf <[EMAIL PROTECTED]>, May 1996
> > *
> > @@ -39,6 +40,12 @@
> > * 8.11.00 Port to Apache 2.0. Read configuation from the
> > configuration
> > * tree rather than reparse the entire configuation file.
> > *
> > + * Rici Lake <[EMAIL PROTECTED]>
> > + *
> > + * 2004-08-28 Rewrote config tree walk using recursion the way God
> > intended.
> > + * Added ?config option. Added printout of config filename and line
> > numbers.
> > + * Fixed indentation.
> > + *
> > */
> >
> >#define CORE_PRIVATE
> > @@ -86,108 +93,97 @@
> >return new;
> >}
> >
> > -static void mod_info_html_cmd_string(request_rec *r, const char
> > *string,
> > - int close)
> > +static void mod_info_indent(request_rec * r, int nest, const char*
> > thisfn, int linenum)
> >{
> > -const char *s;
> > -
> > -s = string;
> > -/* keep space for \0 byte */
> > -while (*s) {
> > -if
Re: Removing the Experimental MPMs in 2.2?
On Fri, 2004-09-03 at 12:56 +0200, Graham Leggett wrote:
> Perhaps a warning on httpd startup should be added to make it clear the
> modules are experiemental:
>
> Warning: The perchild module is EXPERIMENTAL, please use at own risk.
>
That is a little more extreme, but attached is a simple change to the
configure.in to print out another warning when anyone uses an
experimental MPM. This is done at the very very end of the configure
process.
Sample Output:
WARNING: THE 'leader' MPM IS EXPERIMENTAL
The selected MPM might not be fully functional!
Development of this MPM is not complete. Do not use this
MPM unless you are a programmer willing to help fix it.
If you are looking for a stable server, you should not use
the 'leader' MPM until it is moved out of experimental.
Anyone against committing the attached patch?
-Paul Querna
Index: configure.in
===
RCS file: /home/cvs/httpd-2.0/configure.in,v
retrieving revision 1.267
diff -u -r1.267 configure.in
--- configure.in 2 Sep 2004 17:29:13 - 1.267
+++ configure.in 5 Sep 2004 07:57:42 -
@@ -581,3 +581,22 @@
APACHE_GEN_MAKEFILES
])
+case $MPM_SUBDIR_NAME in
+*experimental*)
+echo ""
+echo ""
+echo ""
+echo "WARNING: THE '${APACHE_MPM}' MPM IS EXPERIMENTAL"
+echo ""
+echo " The selected MPM might not be fully functional!"
+echo ""
+echo " Development of this MPM is not complete. Do not use this"
+echo " MPM unless you are a programmer willing to help fix it."
+echo ""
+echo " If you are looking for a stable server, you should not use"
+echo " the '${APACHE_MPM}' MPM until it is moved out of experimental."
+echo ""
+echo ""
+echo ""
+;;
+esac
IfModule in the Default Config
A couple months the IfModule block was modified so that it can use
foo_module instead of the Source File name (ie foo.c).
I believe that using the ${name}_module syntax is clearer than using the
source file name. I would like to encourage using this newer syntax in
the 2.2 Stable Cycle.
Currently PHP users must use:
Using the Source File name seems completely non-intuitive to me.
In 2.1 they can use:
This seems more logical to me.
I would like to change the default httpd.conf.in to use this syntax
instead of the source file name.
Anyone (+|-)1 for it?
If I don't hear anything, I will do it in a couple days.
Thanks,
-Paul Querna
Re: Shorten the default config and the distribution (was: IfModule in the Default Config)
On Tue, 2004-09-14 at 08:14 +0200, Andrà Malo wrote: > I'm rather for removing the whole crap from the default config and simplifiy > as much as possible. > > A >30 KB default config, which nobody outside this circle here > really understands, isn't helpful - especially for beginners. +1
Bundling APR in 2.2
In most of the Apache 2.0.XX releases, we have been using a CVS snapshot of APR and APR-Util. I would like to make it an official policy that for the 2.2 cycle, we will never use a CVS snapshot of APR. I believe we should still bundle APR and APR-Util with HTTPd, but we should only use the released versions of each. This will keep it easy for end users, because APR will still be bundled in our Source Distribution. It will also make life much easier for System Packagers. If we only use released versions, APR and APR-Util can be easily placed into separate packages. This will become more important as more standalone applications use APR. Comments/Objections? -Paul Querna
Re: Bundling APR in 2.2
On Thu, 2004-09-16 at 18:13 +0100, Nick Kew wrote: > On Thu, 16 Sep 2004, Paul Querna wrote: > > > In most of the Apache 2.0.XX releases, we have been using a CVS snapshot > > of APR and APR-Util. > > > > I would like to make it an official policy that for the 2.2 cycle, we > > will never use a CVS snapshot of APR. > > That makes httpd releases (relatively frequent) hostage to APR releases > (extremely infrequent) when we need a bugfix in CVS. Is that acceptable? If there is a significant bug in APR, it should be fixed in a release by them. Regarding APR's release frequency, it is my hope that it will become more frequent as a possible side effect of only bundling released versions. However, APR is still their own project, and it is up to them when they do a release. > > I believe we should still bundle APR and APR-Util with HTTPd, but we > > should only use the released versions of each. > > Release version ABI yes. Release version - only if that dependency > can be fixed (i.e. APR folks can be hurried along where necessary). I guess we should ask them if they can make releases more often :-) > > > > It will also make life much easier for System Packagers. If we only use > > released versions, APR and APR-Util can be easily placed into separate > > packages. This will become more important as more standalone > > applications use APR. > > Keeping binary-compatibility (ABI) is sufficient for that, innit? No. We have a backwards binary compatibility policy. This means existing functions and public structures will not change. It does allow new functions, structures or interfaces to be added. When these things are added, and then used in Apache, we must then wait for them to appear in an APR Release. -Paul Querna
Moving httpd-2.0 to Subversion
The Original Proposal was in March of this year: http://marc.theaimsgroup.com/?t=10791831443&r=2&w=2 +1 Votes: Tom May Justin Erenkrantz Andrà Malo Erik Abele Jim Jagielski Bill Stoddard Joe Orton -1 Votes: Aaron Bannert Aaron said: > This will, at least for now, raise the bar to entry for contributors. While Subversion had recently become 1.0.0 back in March, I believe that Subversion Clients are available for most platforms now, and that the barrier to entry for subversion is not any higher than CVS for new contributors. Is this still a valid concern? A large portion of the thread was taken up by discussions about the various security features of subversion. I believe that it was generally agreed that Subversion is better than CVS in this respect, and further concerns should be taken to [EMAIL PROTECTED] What are the barriers to moving to Subversion? I believe we might as well do it now, before we start on a new stable branch (2.2). Time for another Vote? -Paul Querna
Re: Moving httpd-2.0 to Subversion
On Fri, 2004-09-17 at 07:57 +0200, Sander Striker wrote: > I can't believe I am not in this list... You made the proposal, but didn't say '+1', so at best, it was an implied vote. :)
Re: Moving httpd-2.0 to Subversion
On Fri, 2004-09-17 at 07:57 +0200, Sander Striker wrote: > > What are the barriers to moving to Subversion? > > Other than making the actual decision? None. > > > I believe we might as > > well do it now, before we start on a new stable branch (2.2). Time for > > another Vote? > > Here's my +1. I should note though that we voted to move 1.3 > ages ago, and I managed to drop the ball on that one. When I > finally got around to processing the 1.3 converted CVS > repository, Fitz had removed it from his homedir. > > cvs2svn has seen a release as well, and has been improved a lot > since march. Infrastructure is now totally able to run the > cvs2svn conversion itself. I fully intent to start on the 1.3 > conversion tonight; this time without dropping the ball... Can we set a date for the httpd-2.0 conversion? Say in 10 days put a hold on all non-security commits and do the conversion?
Re: [PING] Re: [PATCH] lingering close thread for worker
On Wed, 2004-09-22 at 15:00 -0400, Bill Stoddard wrote: > > Is there any interest in this patch? Eventually it might > > even be nice to extend the concept to keepalives, but I suppose > > that would mean introducing some state management into > > ap_process_connection. > > > > FWIW, I am definitely interested (especially if we can get confirmation of the > results on several different > platforms from several different folks). greg ames and i have a patch that > essentially does this for > keep-alives, it's been posted to the dev@ list in the recent past. No time to work > on it myself tho, sorry. > Yes, I am interested too. I have taken Greg's patch and turned it into a Full 'event' MPM. I am currently re-working some of apr_pollset_* so I can avoid all locking when adding or removing FDs to a pollset. Once I have the patch to APR done, I planned on submitting the event MPM to be included in CVS. -Paul Querna
Re: new config organization for 2.1
On Fri, 2004-09-24 at 13:12 -0400, Joshua Slive wrote: > A straw-man proposal for a new config organization is at > http://www.apache.org/~slive/newconf/ Looks pretty good. I think this is a good direction to move. Any reason the Netware MPM part cannot be removed from near the top?
Bug 17629: SSI, CGI, and mod_deflate
http://issues.apache.org/bugzilla/show_bug.cgi?id=17629
basic flow inside httpd:
- handler sends output
- mod_include processes. data starts going down the filter chain.
- mod_include sees the need for a CGI (include/virtual/whatever).
- mod_include creates a subrequest. This subrequest uses the same filter
chain.
- If the subrequest is on a CGI, and that CGI sends a redirect
(Location:), mod_cgi{d} creates an internal redirect, which does *not*
use the same filter chain. Any output from this redirect does not get
put into the same chain as the Main Request.
- Meanwhile, mod_deflate, which is on the main request's filter chain,
will gzip encode the content that goes through it.
The end result is mixed gzip and non-gzipped content.
I tried searching the mailing list quickly, but I didn't see any
reasoning why mod_cgi{d} uses an internal redirect for these cases.
The easy solution is to make mod_cgi{d} create a full subrequest, that
would therefore use the same filter chain, and therefore mod_deflate
would properly encode the content.
It seems that calling an internal redirect from anywhere in an output
filter is completely wrong.
Is there any reason not to switch mod_cgi{d} to use subrequests? If no
one objects, I will do it in a couple days.
Thanks,
-Paul Querna
Re: buffered logs + piped logs
Brian Akins wrote: I would like to be able to have "external" logging, so I can rotate with out a restart. I would also like to still be able to do graceful restarts. I thought about using unix domain sockets. I didn't want to replicate someone else's work. I couldn't find anything on google. Any suggestions (doen's have to use unix sockets)? mod_log_spread: http://www.backhand.org/mod_log_spread/
Re: [RFC] Patch for mod_log_config to allow conditioning on status code
Glenn Strauss wrote: On Fri, 15 Oct 2004, Luc Pardon wrote: What are the general requirements to getting a patch or module included in the contrib/ directory? And on that topic, what happened to http://www.apache.org/dist/httpd/contrib/ ? I think /contrib/ is dead. I would rather look at committing your patch to httpd CVS. I don't have any objections to it on a concept level, but I have not reviewed your code in detail. -Paul Querna
Re: Roadmap Apache 2.1 / 2.2
Rüdiger Plüm wrote: Hi all, as some people here are already talking about Apache 2.2, just a short question: Will there ever be a productive version of Apache 2.1 or is it planned to rename the current Apache 2.1-dev into Apache 2.2.0 as soon as Apache 2.1-dev is regarded feature complete and its code having a production grade quality? More or less, that is correct. Please see: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/VERSIONING?view=markup
Re: cvs commit: httpd-2.0/modules/aaa mod_authnz_ldap.c
[EMAIL PROTECTED] wrote: minfrin 2004/10/04 16:43:20 Modified:.CHANGES modules/aaa mod_authnz_ldap.c Log: mod_auth_ldap: Handle the inconsistent way in which the MS LDAP library handles special characters. It seems like this is something that belongs in APR-Util. Wouldn't any application that needed to escape characters in an LDAP filter end up copying this code? Maybe APR-Util should have a _escape(...) type function instead of clogging up httpd with #ifdefs, because if anyone else ever uses APR-Util for ldap, they will end up copying this code to make their stuff portable. Stuff to make LDAP more portable should go into APR...? -Paul Querna
Re: cvs commit: httpd-2.0/modules/aaa mod_authnz_ldap.c
Graham Leggett wrote: This block of code definitely belongs in apr-util, you are 100% right - but moving it to apr-util is a completely separate issue to fixing the bug as committed. Then this 'bug' should be submitted as a bug in APR-Util, not httpd. So far this code will only be moved in httpd v2.1/v2.2 and apr v1.0, none of the apr-util restructuring was to be backported to httpd v2.0/apr v0.9, as the LDAP stuff is experimental in v2.0 anyway (it's not experimental in v2.1/v2.2). So, the answer still seems to get the changes into APR-Util 1.X. If it can be later back ported to 0.9.X, great, if not, hopefully we will have an httpd-2.2 release sometime soon.
Re: Bug: Apache hangs if script invokes fork/waitpid
Jeff Trawick wrote: I think there needs to be a mod_fork which provides a more general purpose daemon than that used by mod_cgid, and some Apache API will know whether or not to send a request over there. This preserves the goal of having fork() called only by single-threaded processes so that all manner of pain is avoided. Big +1 from me in concept. I am not sure how to do the implementation best. mod_cgid doesn't really 'fork' in the sense most programs do, its mostly just starting up a cgi process -- from an executable on the file system. This seems drastically different from the requirements of a generic fork(). Any thoughts on how you would want to implement this in a generic manner for any call from anywhere for any module? -Paul Querna
Capturing a Subrequest
I am trying to capture the content of a sub request that I create in my
module (mod_transform) to a bucket brigade. I want to do this so libxml2
can use it as an input buffer. As an example, this would allow
mod_transform to XInclude content from another Handler (PHP, mod_perl,
or my own module...).
I looked through the mail archives & google, and couldn't find anyone
else that has done this.
Some people tried doing it with mod_perl more than a year ago, but ended
up fetching it over HTTP via LWP, not capturing the output of a sub
request.
I cannot seem to get my output filter ran by Apache. I tried tracing
through it with GDB, but it is being quite stubborn on my sparc tonight.
My output filter looks like:
static apr_status_t
apachefs_filter(ap_filter_t * f, apr_bucket_brigade * bb)
{
apr_status_t rv;
apr_bucket_brigade *data = f->ctx;
rv = ap_save_brigade(f, &data, &bb, f->r->pool);
f->ctx = data;
return rv;
}
However, my capturing output filter doesn't seem to ever be called.
So, I think something about my manually adding my output filter
to the subrequest is wrong:
ap_filter_t cf;
cf.frec = ap_get_output_filter_handle(APACHEFS_FILTER_NAME);
cf.next = NULL;
cf.ctx = input_ctx->bb;
cf.r = f->r;
cf.c = f->c;
rr = ap_sub_req_lookup_uri(URI, f->r, &cf);
rr_status = ap_run_sub_req(rr);
If I pass NULL as the 3rd arg to ap_sub_req_lookup_uri(...) it will use
my current request's filters. I don't want the content sent to the
client, I just want it buffered to a bucket brigade.
Is there a better way to do this?
-Paul Querna
Re: Capturing a Subrequest
Cliff Woolley wrote: On Fri, 8 Oct 2004, Paul Querna wrote: So, I think something about my manually adding my output filter to the subrequest is wrong: Ya, that doesn't look right. There a function that's called (or at least used to be called ;) "ap_add_output_filter()". That's probably what you want. Thanks for the reality check. It works now. :) -Paul
Event MPM
Several months ago, Greg Ames posted [1] his 'Event Driven MPM' patch as a diff to the Worker MPM: http://apache.org/~gregames/event.patch I took this patch as the starting point for my 'Event MPM'. My Patch is split into two parts. First is a patch to APR that provides an extension to apr_pollset that optionally make some parts of it threadsafe. This patch has been submitted to APR before, and hopefully it will get accepted there soon. The other patch is the actual MPM and with a few changes to other parts of the source to take advantage of the Event Thread for handling Keep Alive Requests. These patches total over 160k. Since many mail servers are extremely lame, I have put them up on the web at: http://www.apache.org/~pquerna/event-mpm/ MPM Structure: I have made the MPM a single process with multiple threads It currently does not spawn new threads on demand, but I plan to add this soon. By making it run as a single process, I was able to completely remove the accept() locking. This also greatly simplifies the Listener Thread's poll()`ing of the sockets. The Listener thread includes all the Sockets that it is listening to for incoming requests on in the same pollset as all requests waiting for IO/KeepAlive. Greg's original patch had a separate 'Event' Thread, but I have chosen to combine them. This can also be extended to include the Lingering Close patch that Joe Schaefer submitted [2] this August. The Worker Threads work much like the 'Worker' MPM, but when a connection is ready for a Keep Alive, they will push the client back to the Listener/Event Thread. This thread does not need to be woken up like in Greg Ames' patch. This is because of the enhancement to apr_pollset that enables other threads to _add() or _remove() while the main thread is inside a _poll(). Super-Quick-Yet-Little-Real-Meaning-Benchmarks of Requests per second: Non-KeepAlive: `ab -c 25 -n 10 http://10.10.10.10:6080/index.html` Worker MPM: 2138.28 Event MPM: 2147.95 KeepAlive: `ab -k -c 25 -n 10 http://10.10.10.10:6080/index.html` Worker MPM: 4396.38 Event MPM: 4119.40 (This is using the EPoll backend on a Linux 2.6 Machine, over 100mbit LAN.). The place where the Event MPM should shine is with the more common case of relatively high-latency Internet clients. The Event MPM isn't super powerful on the KeepAlive-over-LAN case because it forces a context switch to process the client again when it is does another request as part of a KeepAlive. I would like to get this into 2.1 CVS relatively soon. I plan to spend more time cleaning it up and tuning it this week. I know this email is light on some of the implementation details, feel free to ask about anything I did :) I would love feedback on all aspects of the patch. Please feel free to rip it apart :) -Paul Querna [1] http://marc.theaimsgroup.com/?t=10867050341&r=1&w=2 [2] http://marc.theaimsgroup.com/?t=10934643134&r=1&w=2
Re: cvs commit: httpd-2.0/server protocol.c
Graham Leggett wrote: Rici Lake wrote: I believe that ap_log_rerror() inserts the OS error description, resulting in something like: [client 127.0.0.1] (70007)The timeout specified has expired: request line read error Of course, this is OS dependent. That still means little to me as an end user, as I would think a "request line read error" was some OS error that I needed to be concerned about, leading me on a wild goose chase. What would make more sense is "Error while reading HTTP request line. (remote browser didn't send a request?)". This indicates exactly what httpd was trying to do when the error occurred, and gives a hint of why the error might have occurred. Well.. Apache isn't just an HTTP server right? Now Committed: "Error while reading request line. (client didn't send a request?)" I also changed it to a INFO. I forgot how much NOTICE sucked. Thanks for the comments. -Paul
Re: Event MPM
Brian Akins wrote: Paul Querna wrote: Non-KeepAlive: `ab -c 25 -n 10 http://10.10.10.10:6080/index.html` Worker MPM: 2138.28 Event MPM: 2147.95 KeepAlive: `ab -k -c 25 -n 10 http://10.10.10.10:6080/index.html` Worker MPM: 4396.38 Event MPM: 4119.40 Have you tried it with higher number of clients -- i.e,. -c 1024? Nope. I was already maxing out my 100mbit LAN at 25 clients. I don't have a good testing area for static content request benchmarking. I am thinking of trying to find an old pentium I with PCI and putting a GigE card in it just for benchmarking. The current patch does not spawn new threads on demand. You need to set "ThreadsPerChild 1200" to test that many clients. This is on my short list of things to change before committing the Event MPM to CVS. We are interesting in the event mpm mainly for dealing with keep alives. Yes, this is the target the Event MPM aims at :) -Paul Querna
Re: Event MPM
Greg Ames wrote: First is a patch to APR that provides an extension to apr_pollset that optionally make some parts of it threadsafe. This patch has been submitted to APR before, and hopefully it will get accepted there soon. I need to catch up here. quick questions: will this event MPM work with conventional poll (i.e. no epoll or kqueue)? Can it handle a worker thread adding directly to the pollset? The patch to APR adds a new 'APR_POLLSET_THREADSAFE' flag for apr_pollset_create(...). This only works for the EPoll and KQueue backends. This allows a worker thread to _add() or _remove() directly, without having to touch the thread in _poll(). It could be implemented for plain Poll by having the pollset contain an internal pipe. This Pipe could be pushed by an _add() or _remove() and force the _poll() thread to wake up. The thread in _poll() could then add or remove any sockets from it's set, and then start the _poll() again. This is how your original patch did it, but we could push it down to APR. I don't think in the end it will yield good performance with this method. My personal view is that most platforms will have either EPoll() or KQueue() Support. I guess its only an issue for people running 2.2./2.4 Linux, since KQueue has been in *BSD for a long time. As time passes, I believe that implementing it for plain poll() will be come less important. Other platforms like Solaris have better poll() replacements that we should add to apr_pollset_*. [...snip...] I have made the MPM a single process with multiple threads > interesting! but then per process limits (fd's esp. for sockets, virtual memory) could put a ceiling on how high this can scale. Plus if a buggy module seg faults, it's a lot more disruptive when there's only one worker process. We don't have buggy modules :-) Isn't the per-process FD limit only really a problem for platforms like older Solaris? I thought that on Linux/BSD it is quite high by default now. It currently does not spawn new threads on demand, but I plan to add this soon. By making it run as a single process, I was able to completely remove the accept() locking. This also greatly simplifies the Listener Thread's poll()`ing of the sockets. understood, but see above. My vote is to keep it multiprocess capable and perhaps allow a single process ./configure option. I am not completely adverse to putting multi-processes back in, I mostly wanted to get a working patch out there for review. The current logic used in Worker is flawed for poll`ing of Listening sockets. I just ripped all of it out, and ended up with a much simpler MPM that avoids extra locking. [...snip...] The Worker Threads work much like the 'Worker' MPM, but when a connection is ready for a Keep Alive, they will push the client back to the Listener/Event Thread. This thread does not need to be woken up like in Greg Ames' patch. This is because of the enhancement to apr_pollset that enables other threads to _add() or _remove() while the main thread is inside a _poll(). even with plain ol' vanilla poll() ? Nope. Its just not easily to implement and support plain old vanilla poll(). You cannot just add an FD to its array of sockets from other threads. The poll() will also not see any changes in its list until you wake it up, and start the poll() again. This is not impossible to implement, but its going to have a huge number of context switches for what should be a very common operation. [...snip..] The place where the Event MPM should shine is with the more common case of relatively high-latency Internet clients. The Event MPM isn't super powerful on the KeepAlive-over-LAN case because it forces a context switch to process the client again when it is does another request as part of a KeepAlive. I heard of an application where many clients send a heartbeat to a server over http every few seconds. That would benefit greatly by using keepalives and some form of event MPM, even over a LAN. Yup. Another place the event MPM would rock is on an FTP server. (see mod_ftpd). Yet Another place is an IMAPv4 server written as an Apache Module. (This is on my ~/TODO list) Thanks for the Feedback! -Paul Querna
Re: Event MPM
Brian Pane wrote: How about modifying ab to add a delay of a second or two between successive read(2) calls on the same connection (and limiting the max read size to a small value, to make sure each response requires multiple reads)? The throughput numbers wouldn't be very impressive, of course, but you'd be able to see how much memory and how many threads the Event MPM uses in handling a real-world number of concurrent connections, compared to Worker. +1, I will look at patching this tonight. I think some other HTTP benchmarkers might already have this feature. Flood? The current patch does not spawn new threads on demand. You need to set "ThreadsPerChild 1200" to test that many clients. This is on my short list of things to change before committing the Event MPM to CVS. This part seems surprising. What's the relationship between clients and threads in the Event MPM--does it use a thread per connection? A thread per-connection that is currently being processed. Note that this is not the traditional 'event' model that people write huge papers about and thttpd raves about, but rather a hybrid that uses a Worker Thread todo the processing, and a single 'event' thread to handle places where we are waiting for IO. (Currently accept() and Keep Alive Requests). Perhaps it needs a different name? (eworker?) A future direction to investigate would be to make all of the initial Header parsing be done Async, and then switch to a Worker thread to preform all the post_read hooks, handlers, and filters. I believe this could be done without breaking many 3rd party modules. (SSL could be a bigger challenge here...) I haven't had a chance to check out the Event MPM yet, but I'm planning to download it and study the code later this week. For what it's worth, I can think of at least one killer app for the Event MPM beyond keep-alive handling: as an efficient (low memory & thread use per connection) connection multiplexer in front of an inefficient (high memory & thread use per connection) appserver. Yes, another thing on my ~/TODO is to use this design this as the base for a perchild replacement. My idea is to use a lightweight 'event' frontend to determine which backend to pass a socket to. These backends would be running as different UIDs, and could be running a threaded or non-threaded manner to optionally support PHP. -Paul Querna
Re: Event MPM
Paul Querna wrote: > A thread per-connection that is currently being processed. Note that this is not the traditional 'event' model that people write huge papers about and thttpd raves about, but rather a hybrid that uses a Worker Thread todo the processing, and a single 'event' thread to handle places where we are waiting for IO. (Currently accept() and Keep Alive Requests). Perhaps it needs a different name? (eworker?) A future direction to investigate would be to make all of the initial Header parsing be done Async, and then switch to a Worker thread to preform all the post_read hooks, handlers, and filters. I believe this could be done without breaking many 3rd party modules. (SSL could be a bigger challenge here...) Some academics have played with this model of a event thread + worker threads. Best I can find is the Java 'SEDA: An Architecture for Highly Concurrent Server Applications'. [1] They have some pretty graphs in their papers of their Haboob web server that can scale very nicely compared to traditional event or pure-threaded servers.[2] [3] -Paul Querna [1] http://www.eecs.harvard.edu/~mdw/proj/seda/ [2] http://www.enhyper.com/content/eventsbadidea.pdf [3] http://www.cis.upenn.edu/~hhl/cse434/lectures/seda.pdf
Re: Event MPM
Greg Ames wrote: Brian Akins wrote: Can you still have multiple processes? We use 10k plus threads per box with worker. with my patch, yes. with Paul's, no. Correct at the moment. I think based on the feedback so far, I will investigate making it multi-processed again.
Re: Event MPM
Greg Ames wrote: Brian Akins wrote: We have some home grown benchmarks that may could help, If they simulate user think time or would otherwise cause a lot of keepalive timeouts, great! Finding the right client/benchmark is a problem for me right now and I believe for Paul too. Yup. This is my biggest problem right now with the benchmarks. `ab` just doesn't give a realistic modeling of how clients use Keep Alives. If you have some home grown programs that do, I would love to use them.
Event MPM w/ multiple processes
Brian Akins wrote: Greg Ames wrote: one thread per connection with an active http request, plus the listener/event thread who owns all the connections in keepalive. I believe Paul is saying set ThreadsPerChild to 1200 to handle the worst case behavior - 100% of the connections are doing real work at some instant and none are in keepalive timeouts. Can you still have multiple processes? We use 10k plus threads per box with worker. The updated patch for today adds multiple processes. (same directives as the worker MPM): http://www.apache.org/~pquerna/event-mpm/event-mpm-2004-10-25.patch However, the big thing it doesn't use is accept serialization. This means all event threads are listening for incoming clients. The first one to process the incoming connection gets it. This does not block the other event threads, since they set the listening socket to non-blocking before starting their loop. This seems to work fine on my tests. It has the sucky side effect of waking up threads sometimes when they are not needed, but on a busy server, trying to accept() will likely be fine, as there will be a backlog of clients to accept(). -Paul Querna
mod_cache: Content Generation Dependencies?
I have been doing some stuff with mod_transform (XSLT processor) and mod_cache. The problem is, mod_cache doesn't have any easy way to know if a request needs to be regenerated. Right now, it just blindly caches until a timeout. What I would prefer is that it knows what files or URLs a specific request depends upon, and if any of those change, then regenerate the request. An example: cache_add_depends(r, "/home/httpd/site/xsl/foo.xsl"); This would add 'foo.xsl' as a dependency of the current request. If the file's mtime changes, mod_cache would invalidate the cache of the current request. Any opinions or suggestions? A stat() call on several files is hundreds of times faster than having mod_transform re-generate the output. While I would hate to stat() hundreds of files on every request, this method could eliminate all unesesary regeneration of cached content. -Paul Querna
Re: Event MPM w/ multiple processes
Greg Ames wrote: However, the big thing it doesn't use is accept serialization. hmmm, that would be challenging with a merged listener/event thread. If the event thread is blocked waiting for its turn to accept(), it can't react to a poll popping due to an older connection becoming readable. Yup. I am thinking about different ways of passing the listening sockets around. Both EPoll and KQueue support methods to cheaply disable an FD in their pollset. It just needs exposure in the APR API. This means all event threads are listening for incoming clients. The first one to process the incoming connection gets it. This does not block the other event threads, since they set the listening socket to non-blocking before starting their loop. > This seems to work fine on my tests. It has the sucky side effect of waking up threads sometimes when they are not needed, but on a busy server, trying to accept() will likely be fine, as there will be a backlog of clients to accept(). short war story: we had a bug a couple of years ago where whenever we tried putting the latest httpd into production on daedalus, the load average spiked way up. Brian B and Manoj would get paged. It was caused by using unserialized poll()s rather than unserialized accept()s in the prefork mpm. But that was 200-300 unthreaded processes each using plain ol' vanilla poll() on one or two fd's. I'm thinking we would want to tune for 2-3 processes with the event mpm so this shouldn't be the same situation. That was my feeling aswell. The 'thundering herd' problem isn't as signifigant with a relatively small number of Event MPM Processes, compared to 1000+ Prefork Childern. -Paul
Updated Event MPM Patches
Updated patches: http://www.apache.org/~pquerna/event-mpm/event-apr_pollset-2004-11-01.patch http://www.apache.org/~pquerna/event-mpm/event-mpm-2004-11-01.patch pollset: Fix the KQueue backend to set APR_POLLHUP on EOF instead of APR_POLLERR. (Thanks to Justin for leading me to this one.) event-mpm: Based on Greg's patch for pipelined requests. Seems to work here. This does not fix the case for SSL+pipelined requests. -Paul Querna
Re: [PATCH] pipelining bug in Event MPM
Justin Erenkrantz wrote: --On Monday, November 1, 2004 6:06 PM -0500 Greg Ames <[EMAIL PROTECTED]> wrote: Given the timeframe and the fact that my schedule just sucks for the next two weeks, is there enough interest (and presence) to discuss this at the Hackathon next weekend in LV? wish I could be there physically, but I can't :( Maybe IRC? Absolutely. We should come up with a schedule and post it to [EMAIL PROTECTED] and have those who can't be there in person chime in electronically. -- justin I would love to have a time to discuss this at the Hackathon. -Paul
Re: TLS session ticket key (shared) renewal
My thought was to add support for either multiple files, or multiple values in the existing `SSLSessionTicketKeyFile`. Then add support to decrypt from any of the known keys, and have a setting (or the first loaded key) would be used to encrypt all new keys. This would allow for rotation in a reasonable manner. On Fri, Mar 18, 2016 at 6:55 AM, Yann Ylavic wrote: > Currently this can be done by using a (shared) SSLSessionTicketKeyFile > and gracefuly restarting httpd instances, but there is room for > improvements here. > > Thoughts? >
Re: TLS session ticket key (shared) renewal
On Tue, Mar 22, 2016 at 3:32 PM, Yann Ylavic wrote: > On Tue, Mar 22, 2016 at 4:18 PM, Paul Querna wrote: > > My thought was to add support for either multiple files, or multiple > values > > in the existing `SSLSessionTicketKeyFile`. Then add support to decrypt > from > > any of the known keys, and have a setting (or the first loaded key) > would be > > used to encrypt all new keys. This would allow for rotation in a > reasonable > > manner. > > That's indeed a great improvement on what we have now, and actually > looks like you first introduced it in r1200040 :) > Why was it not kept that way? > > We'll still need a (graceful) restart to renew the keys, though. > (unix mpms) Having the a process (mpm_register_timed_callback? other hooks?) re-read the file periodically or on change, and set them set it in a slot mem is reasonable, but not the behavior of almost any other file reference in httpd... so the pattern of graceful is how most things work, I can't figure out why session tickets are worth an exception to this pattern? > Also, it seems there is interest in sharing the keys accross different > instances/machines, is a file (unless on something like an NFS mount) > an option here? > Most large scale deployments have configuration management or other techniques to synchronize secret values across many machines; I don't think we should go overboard in building a network transport for session ticket secrets.
Too many knobs
Saw this today, and noticed they used httpd as one of the projects they collected data about: http://neverworkintheory.org/2016/06/09/too-many-knobs.html http://cseweb.ucsd.edu/~tixu/papers/fse15.pdf Hard to make a quick conclusion, but I do believe in the general statement of enumerations > numeric config options and having good defaults.
Re: svn commit: r427920 - /httpd/httpd/trunk/modules/proxy/mod_proxy.c
Please review the code style guidelines:
http://httpd.apache.org/dev/styleguide.html
In the following revisions I found things that I consider to not be in
line with the guidelines:
427920
427928
428008
428029
Specifically, most of them are missing { and } around one life if/else
statements.
Comments inline bellow...
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Tue Aug 1 23:54:01 2006
New Revision: 427920
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=427920&r1=427919&r2=427920&view=diff
==
--- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Tue Aug 1 23:54:01 2006
@@ -1605,6 +1605,7 @@
proxy_balancer *balancer = NULL;
proxy_worker *worker = NULL;
const char *err;
+int in_proxy_section = 0;
if (cmd->directive->parent &&
strncasecmp(cmd->directive->parent->directive,
@@ -1616,6 +1617,7 @@
name = ap_getword_conf(cmd->temp_pool, &pargs);
if ((word = ap_strchr(name, '>')))
*word = '\0';
+in_proxy_section = 1;
}
else {
/* Standard set directive with worker/balancer
@@ -1627,15 +1629,32 @@
if (strncasecmp(name, "balancer:", 9) == 0) {
balancer = ap_proxy_get_balancer(cmd->pool, conf, name);
if (!balancer) {
-return apr_pstrcat(cmd->temp_pool, "ProxySet can not find '",
- name, "' Balancer.", NULL);
+if (in_proxy_section) {
+err = ap_proxy_add_balancer(&balancer,
+cmd->pool,
+conf, name);
+if (err)
+return apr_pstrcat(cmd->temp_pool, "ProxySet ",
+ err, NULL);
For example, this code block should be:
if (err) {
return apr_pstrcat(cmd->temp_pool, "ProxySet ",
err, NULL);
}
+}
+else
+return apr_pstrcat(cmd->temp_pool, "ProxySet can not find '",
+ name, "' Balancer.", NULL);
And this should be:
}
else {
return apr_pstrcat(cmd->temp_pool, "ProxySet can not find '",
name, "' Balancer.", NULL);
}
Thanks,
Paul
Re: svn commit: r428700 - /httpd/httpd/branches/httpd-proxy-scoreboard/modules/mem/sharedmem_util.c
[EMAIL PROTECTED] wrote:
Author: jfclere
Date: Fri Aug 4 04:44:01 2006
New Revision: 428700
URL: http://svn.apache.org/viewvc?rev=428700&view=rev
Log:
Remove shared memory before creating it. (That only removes the file!).
Modified:
httpd/httpd/branches/httpd-proxy-scoreboard/modules/mem/sharedmem_util.c
Modified:
httpd/httpd/branches/httpd-proxy-scoreboard/modules/mem/sharedmem_util.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/httpd-proxy-scoreboard/modules/mem/sharedmem_util.c?rev=428700&r1=428699&r2=428700&view=diff
==
--- httpd/httpd/branches/httpd-proxy-scoreboard/modules/mem/sharedmem_util.c
(original)
+++ httpd/httpd/branches/httpd-proxy-scoreboard/modules/mem/sharedmem_util.c
Fri Aug 4 04:44:01 2006
@@ -210,12 +210,15 @@
}
ptr = ptr + sizeof(desc);
} else {
-if (name && name[0] != ':')
+if (name && name[0] != ':') {
+apr_shm_remove(fname, globalpool);
rv = apr_shm_create(&res->shm, item_size * item_num +
sizeof(struct sharedslotdesc), fname, globalpool);
-else
+} else {
rv = apr_shm_create(&res->shm, item_size * item_num +
sizeof(struct sharedslotdesc), NULL, globalpool);
This line should be:
}
else {
Thanks,
-Paul
Re: Product name - for future versions
William A. Rowe, Jr. wrote: > Colm MacCarthaigh wrote: >> On Thu, Aug 10, 2006 at 12:26:23PM -0700, William A. Rowe, Jr. wrote: >>> Pretty darned quiet - either "it's summer" or nobody feels like >>> joining the fray when Roy and Will go at it? >> Well, Paul's talk in San Diego got me thinking. We're not really "just" >> about HTTP any more, it's a misnomer. We're about delivering information >> using many different protocols accross the internet. I don't know, >> something like Internet Information Server just seems more appropriate >> somehow. > > LOL :) Well as I said; focus is on the name of what's /repos/asf/httpd/httpd > today. Granted, "d" might be a bit too general, but I agree with everyone > who's said that the 'next release' aught to get a broader name than just > plain old Apache HTTP Server. Apache ++HTTP Server? Apache Scheme[] Server? > Some wordplay with MPM (since that's by far the distinguishing characteristic > of today's httpd over all previous ones, and colors the implementation of any > protocol that's compiled into the server.) > > Apache Empeem Server? Man, naming incubator projects is hell enough, why bring that kind of wasted time to [EMAIL PROTECTED] On a serious note, For all future 1.3.x and 2.x releases, 'Apache HTTP Server' or whatever the consensus turns out to be is fine by me. I still stand by "Apache Server Framework" as the best choice. The ASF'S ASF is the ultimate way to deliver data from a server :) Anyways, I honestly don't care about this in any real manner until we are much closer to a 3.0 stage. -Paul
Re: [Vote] create [EMAIL PROTECTED]
William A. Rowe, Jr. wrote: > Project Committee Members... > > Adopt [EMAIL PROTECTED], seeded from [EMAIL PROTECTED] > current subscribers, for module authors to use for peer developer support? > (API 'users', essentially.) > > [X] +1 > [ ] +/-0 > [ ] -1
Re: fcgi proxy module to 2.2.x?
Jim Jagielski wrote: Topic for discussion: Add the FCGI proxy module to the 2.2.x distro? I personally would like to get the local-process spawning done first, or has everyone pretty much given up on ever doing that? Otherwise, I guess I'm a -0. I kind of want to have things worth releasing in trunk, so we could in theory (ha, ha, ha, ha!) do a 2.4 branch in 6-10 months. -Paul
Re: info about testing tool
Tenivella Enrico wrote: Hi all. I read about tests tool for apache, I'm searching a script that read from access.log and perform the same request (GET and POST) at the same time Apache Flood? http://httpd.apache.org/test/flood/
Re: load balancer and http(s) sticky sessions
Jim Jagielski wrote: There is a lot of confusion where the users think that simply adding the stickysession param to the http worker attribute *adds* the required sticky session info (cookie). I'm looking into adding functionality that actually does that and therefore avoiding this large and common misconception. I think we should support both methods. Yeah, in many cases, it would be easier if the LB could figure out the stickysession for me. -Paul
Re: load balancer and http(s) sticky sessions
Jim Jagielski wrote: Paul Querna wrote: Jim Jagielski wrote: There is a lot of confusion where the users think that simply adding the stickysession param to the http worker attribute *adds* the required sticky session info (cookie). I'm looking into adding functionality that actually does that and therefore avoiding this large and common misconception. I think we should support both methods. Yeah, in many cases, it would be easier if the LB could figure out the stickysession for me. That's what I'm thinking, sort of like an 'autostickysession' attribute. We could even have it default to cookies but add something like 'autostickysession=url' to force URL rewriting and adding a tag to the end of the URL (for sites that don't like cookies) I don't care about sites that don't like cookies, how about that :) -Paul
Re: svn commit: r451582 - /httpd/httpd/trunk/modules/proxy/mod_proxy.h
Mladen Turk wrote: Ruediger Pluem wrote: URL: http://svn.apache.org/viewvc?view=rev&rev=451582 Log: Move new struct member to the end of the struct, so we can keep the compatibility. Sorry for nitpicking, but I am still missing the minor bump. There was no 2.3 releases, so no need for version bump. We should still maintain the MMN on trunk. Some people do actually use trunk -Paul
Re: svn commit: r451582 - /httpd/httpd/trunk/modules/proxy/mod_proxy.h
Mladen Turk wrote: But the trunk is usually build as is with all custom modules. What's the point of it if we need to preserve backward compatibility. (For what version, SVN head from DD/MM/ or what). When the first version gets tagged from trunk, then we can have a MMN. Until then, the trunk itself is the version. Its not about maintaining compatibility, its about maintaining versioning. Don't confuse the versioning mechanisms with restrictions on changes. Bumping the MMN allows modules to be compiled against trunk, and know when an API has changed. It is perfectly acceptable to break, change, or modify an ABI in trunk at any time, but we still should version it, so anyone interested will have a way to know this. -Paul
Re: mod_disk_cache summarization
Graham Leggett wrote: Davi Arnaut wrote: Have you seen my patch to address this issue ? IMHO, it is far less complex and less expensive then the committed workaround. No - I went through your patches in some detail, but I didn't see one that addressed this problem specifically. Once thundering herd is solved, I plan to commit all your refactoring patches. I didn't like that sleep/fstat hackery. How about using a real file notification scheme ? The prerequisite is that APR needs to be taught about this scheme, and it has to work portably across all platforms. No it doesn't. mod_disk_cache makes many assumptions about the underlying OS, like how moving a file on the same file system is atomic, and how you can move files that have open file descriptors, both of which aren't true with some file systems or operating systems (like uh.. windows). mod_disk_cache is a high performance part, lets make it work great on most unixy/POSIX type platforms, and come back to making it portable later. -Paul
Re: svn commit: r467259 - /httpd/httpd/trunk/modules/proxy/ajp_utils.c
[EMAIL PROTECTED] wrote: Author: mturk Date: Tue Oct 24 00:01:44 2006 New Revision: 467259 ... -rc = ajp_msg_create(r->pool, AJP_HEADER_SZ_LEN+1, &msg); +rc = ajp_msg_create(r->pool, 128, &msg); Please don't use an arbitrary number like this. Make a define, do something, anything but a bare 128 which someone coming along later will have no chance to understand. Also, it looks like the message only contains a unit8. Why does this need 128 bytes? Thanks, -Paul
cgi: KILL_AFTER_TIMEOUT vs KILL_ALWAYS
When creating a subprocess (ie a CGI in this case), APR has several
choices on how to clean it up, when the parent process is exiting or
running a pool cleanup. Using apr_pool_note_subprocess, the choices are:
APR_KILL_NEVER -- process is never sent any signals
APR_KILL_ALWAYS-- process is sent SIGKILL on apr_pool_t cleanup
APR_KILL_AFTER_TIMEOUT -- SIGTERM, wait 3 seconds, SIGKILL
APR_JUST_WAIT -- wait forever for the process to complete
APR_KILL_ONLY_ONCE -- send SIGTERM and then wait
Currently, mod_cgi{d} sets APR_KILL_AFTER_TIMEOUT. It appears however,
on a server under high load (>100 load average), it is possible for only
the initial SIGTERM to be sent. It appears that the SIGKILL was never
sent to the child CGI processes.
I believe that the parent process, which is supposed to have a 7 second
space between its own SIGTERM and SIGKILL, is getting the SIGKILL before
it has slept for 3 seconds *and* sent the final SIGKILL to the child
CGIs. This has the potential to leave broken child processes behind.
In the real world, this didn't happen on just a single machine... but
was widespread over a cluster of machines. About 70% of them had this
problem after an `apachectl stop`.
Attached is a patch to mod_cgi and mod_cgid, which switches it to using
APR_KILL_ALWAYS, which appears to resolve this issue.
Is there anything seriously wrong with using SIGKILL first?
Thanks,
Paul
Index: modules/generators/mod_cgi.c
===
--- modules/generators/mod_cgi.c(revision 467373)
+++ modules/generators/mod_cgi.c(working copy)
@@ -462,7 +462,7 @@
apr_filepath_name_get(r->filename));
}
else {
-apr_pool_note_subprocess(p, procnew, APR_KILL_AFTER_TIMEOUT);
+apr_pool_note_subprocess(p, procnew, APR_KILL_ALWAYS);
*script_in = procnew->out;
if (!*script_in)
Index: modules/generators/mod_cgid.c
===
--- modules/generators/mod_cgid.c (revision 467373)
+++ modules/generators/mod_cgid.c (working copy)
@@ -802,7 +802,7 @@
}
procnew->pid = daemon_pid;
procnew->err = procnew->in = procnew->out = NULL;
-apr_pool_note_subprocess(p, procnew, APR_KILL_AFTER_TIMEOUT);
+apr_pool_note_subprocess(p, procnew, APR_KILL_ALWAYS);
#if APR_HAS_OTHER_CHILD
apr_proc_other_child_register(procnew, cgid_maint, procnew, NULL, p);
#endif
mod_disk_cache in trunk, was Re: mod_disk_cache summarization
Graham Leggett wrote: On Tue, October 24, 2006 9:31 am, Paul Querna wrote: The prerequisite is that APR needs to be taught about this scheme, and it has to work portably across all platforms. No it doesn't. mod_disk_cache makes many assumptions about the underlying OS, like how moving a file on the same file system is atomic, and how you can move files that have open file descriptors, both of which aren't true with some file systems or operating systems (like uh.. windows). As I understand, there is no more file moving inside mod_disk_cache, so this is no longer true. Well, yes, you are right, I finally had time to read some of the changes in trunk, and r450105 is freaking crazy: http://svn.apache.org/viewvc?view=rev&revision=450105 It replaced a cheap atomic operation, with copying the entire file off disk in chunks. How could that ever make sense? The final MOVE of the temp file to the cache file should of had NOTHING to do with making it safe for large files. It seems the patch (and CHANGES entry) did way more than what was described. mod_disk_cache is a high performance part, lets make it work great on most unixy/POSIX type platforms, and come back to making it portable later. I'd rather not do a whole lot of work coming up with a works-for-me cache, and then have to field a whole lot of bug reports (like, say from Windows users ;) ) and then have to fix all the problems that come up by rewriting everything again. mod_disk_cache needs to be high performance yes, but not to the point where that means it's broken on half the platforms. If it works on FreeBSD, Linux, and Solaris on Fridays, its good enough for me. -Paul
Re: mod_deflate and flush?
Sven Köhler wrote: > Hi, > > JSP (via mod_jk) and maybe other plugins sometimes flush the connection, > so that the browsers receive everything that's stuck in some internal > buffer. Here's a quote from mod_jk's docs: mod_deflate supports metadata buckets of the FLUSH type. The best solution (as discussed before in the context of mod_proxy_ajp) is to add a FLUSH message to the AJP protocol, rather than trying to 'guess' when a flush was intended. AFAIK, no one has actually done this yet. -Paul
Re: svn commit: r467655 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/mod_cache.c modules/cache/mod_cache.h
Davi Arnaut wrote: Joe Orton wrote: and we must not slow the caching because of a slow client (that's why I didn't pass the brigade). There is no other acceptable solution AFAICS. Buffering the entire brigade (either to disk, or into RAM as the current code does) before writing to the client is not OK, polling on buckets is not possible, using threads is not OK, using non-blocking writes up the output filter chain is not possible. Any other ideas? I think we should build the necessary infrastructure to solve this problem once and for all. Be it either non-blocking writes, AIO or add support to the core output filter to write data to different destinations. Thats not going to be possible until 3.0. Good luck :) -Paul
Re: svn commit: r468373 - in /httpd/httpd/trunk: CHANGES modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h
Graham Leggett wrote: On Fri, October 27, 2006 6:05 pm, Niklas Edmundsson wrote: The purpose of that code was originally to make "EnableSendfile Off" in the config file work. APR_HAS_SENDFILE only tells you that APR has sendfile. It still does that as far as I can see: #if APR_HAS_SENDFILE core_dir_config *pdconf = ap_get_module_config(r->per_dir_config, &core_module); #endif flags = APR_READ|APR_BINARY|APR_BUFFERED; #if APR_HAS_SENDFILE flags |= ((pdconf->enable_sendfile == ENABLE_SENDFILE_OFF) ? 0 : APR_SENDFILE_ENABLED); #endif It was removed because in the absence of APR_HAS_SENDFILE, it gave a compiler warning. The real fix was to surround it in an ifdef, which has been done. Honestly, I am -1 on any module needing knowledge of the core module setting. We should be making the abstraction better, not pulling things from the core config. -Paul
ROADMAP for mod_cache
I think we have had enough -1s passed over the last couple days related to mod_cache, that it indicates there is not a consensus on what should be done, nor on how it should be done. I think we need to stop committing code for a couple days, and try to make a rudimentary plan for the intended changes to mod_cache, and try to gather some kind of consensus on them, rather than continuing down the path of -1s and long ass mailing list threads. Thoughts? -Paul
