Undocumented core directive: Protocol
On 2010-02-09 at 09:27, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=42912 Developers, Christian Ress kindly contributed documentation for the Protocol directive. I'd like to expand it a bit before committing; can anyone help me with these questions? 1) When you use the Protocol directive, which listening ports is it applied to? 2) Why would you choose to use the Protocol directive, instead of adding the protocol to the Listen directive? Thanks, Dan
Re: Undocumented core directive: Protocol
On Thu, Feb 25, 2010 at 8:03 AM, Dan Poirier poir...@pobox.com wrote: 1) When you use the Protocol directive, which listening ports is it applied to? 2) Why would you choose to use the Protocol directive, instead of adding the protocol to the Listen directive? Looking at this cold, I think the answer to this is that Protocol is per-vhost. -- Eric Covener cove...@gmail.com
Tagging 2.2.15 to play openssl catchup?
I'd like to move ahead and catch up to OpenSSL 0.9.8m which was released today, and that requires a 2.2 release. Let's start a three day clock to the tag, and I'll tag Sunday about noon CST. That gives folks friday, and weekend warriors time Saturday to catch up with final important bugfix backports, and testers can pick this up Sunday afternoon or anytime Monday/Tuesday. WDYAT?
Re: Tagging 2.2.15 to play openssl catchup?
On Thu, Feb 25, 2010 at 4:36 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: I'd like to move ahead and catch up to OpenSSL 0.9.8m which was released today, and that requires a 2.2 release. Let's start a three day clock to the tag, and I'll tag Sunday about noon CST. That gives folks friday, and weekend warriors time Saturday to catch up with final important bugfix backports, and testers can pick this up Sunday afternoon or anytime Monday/Tuesday. WDYAT? +1
Re: svn commit: r912666 - in /httpd/httpd/trunk: CHANGES include/util_mutex.h server/core.c server/util_mutex.c
On 2/24/2010 6:44 AM, Jeff Trawick wrote: On Tue, Feb 23, 2010 at 11:07 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 2/22/2010 11:16 AM, traw...@apache.org wrote: Author: trawick Date: Mon Feb 22 17:16:29 2010 New Revision: 912666 URL: http://svn.apache.org/viewvc?rev=912666view=rev Log: Fix startup segfault when the Mutex directive is used but no loaded modules use httpd mutexes. Add an init call from core's pre-config hook to ensure init is performed before the config is parsed. This logic seems broken. The problem is that anonymous mutexes against a persistant data store can't be closed and reopened between server generations. This use of pre/post config persists the broken design. I guess persist means you believe the whole Mutex implementation doesn't allow persistent mutexes. See below for an attempt to split two different aspects -- Mutex directive vs. APR mutex. This layer of init really should happen against process pool, within the scope of the register hooks. No? There's no hassle for a named mutex object that corresponds to the persistent object, e.g. a named file lock against a named database. Requirement 1: Modules can create mutexes that persist across restarts. Requirement 2: Configuration of mutexes can change across restart and, for example, removing a Mutex directive across restart would cause a mutex subsequently created of that type to use default settings. A mutex that persists across restarts will not pick up configuration changes, but there's no magic solution for that. There can be within reason. I'm working on using the mutex API within the http://people.apache.org/~wrowe/mod_usage_track.c module in such a way that any change to the mutex setting will cause a new process-lifetime mutex to be used, and no change to the mutex setting will cause the same process-lifetime mutex to persist. So for scoreboard sorts of process lifetime resources, the unnamed mutex should survive server generations. Let me see if I can transition my work from mod_usage_track and mod_ssl before, and integrate these into the ap mutex creation API.
Re: libapreq 2.12 failing with apache 2.2.14
Howdy, Just built libapreq 2.12 on 64 bit CentOS 5.4 with Perl 5.10.1 and Apache 2.2.14, and found two things I wanted to follow up on here: 1. The build initially failed with this error: /usr/lib/libexpat.so: could not read symbols: File in wrong format This appears to be because I have 64 bit Apache and apreq, but that library is 32 bit. To get apreq to use the 64 bit version, I had to configure like so: LDFLAGS=-L/usr/lib64 ./configure --with-apache2-apxs=/path/to/apxs So is there some way that apreq2's configure script could be updated to look for /usr/lib64 and perhaps /lib64 and /usr/local/lib64 on 64 bit platforms? 2. I got a bunch of Perl test failures, but it looks like they were known. It doesn't look like this patch has been applied yet: http://marc.info/?l=apreq-devm=125501679623914 Should it be? Thanks, David
Re: Tagging 2.2.15 to play openssl catchup?
On 25 Feb 2010, at 11:36 PM, William A. Rowe Jr. wrote: I'd like to move ahead and catch up to OpenSSL 0.9.8m which was released today, and that requires a 2.2 release. Let's start a three day clock to the tag, and I'll tag Sunday about noon CST. That gives folks friday, and weekend warriors time Saturday to catch up with final important bugfix backports, and testers can pick this up Sunday afternoon or anytime Monday/Tuesday. WDYAT? +1. Regards, Graham --
