Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 72995 invoked from network); 17 Jan 2008 09:58:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Jan 2008 09:58:42 -0000 Received: (qmail 73193 invoked by uid 500); 17 Jan 2008 09:58:28 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 73124 invoked by uid 500); 17 Jan 2008 09:58:28 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 73113 invoked by uid 99); 17 Jan 2008 09:58:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Jan 2008 01:58:28 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.245.8.254] (HELO ania) (83.245.8.254) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Jan 2008 09:58:11 +0000 Received: by ania (Postfix, from userid 1025) id C2541381677E3; Thu, 17 Jan 2008 09:58:03 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on ania.pc-tony.com X-Spam-Level: Received: from mail.pc-tony.com (unknown [127.0.0.1]) by ania (Postfix) with ESMTP id 9BA8838077B89 for ; Thu, 17 Jan 2008 09:58:01 +0000 (UTC) Received: from 80.168.22.106 (SquirrelMail authenticated user tonys) by mail.pc-tony.com with HTTP; Thu, 17 Jan 2008 09:58:01 -0000 (UTC) Message-ID: <19079.80.168.22.106.1200563881.squirrel@mail.pc-tony.com> In-Reply-To: <2C15D00D262B7245B1D8D1799F04D88F072FF094@mtw01ex01.mindtree.com> References: <200801170446.m0H4kruZ007182@Boron.MeepZor.Com> <2C15D00D262B7245B1D8D1799F04D88F072FF094@mtw01ex01.mindtree.com> Date: Thu, 17 Jan 2008 09:58:01 -0000 (UTC) Subject: Re: Apache service problem. make_sock: could not bind to address. From: "Tony Stevenson" To: dev@httpd.apache.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Ashwani, Your email needs to be redirected to users@httpd.apache.org This list (dev@) is for the people interested in the development of the HTTP Server. Alternatively look here, and use the IRC option. http://httpd.apache.org/docs/2.2/faq/ Tony On Thu, January 17, 2008 9:44 am, Ashwani Kumar Sharma wrote: > > Hi All, > > > While trying to run apache service on windows I faced this strange > problem. I have installed IPv6 on this machine. > > If I make apache run on some port no which is not free. I don't see any > logfile being created in the apache/log directory. > > While I try to run the httpd.exe from the command prompt with same port > no. I see following error message on the console. > > "(OS 10048)Only one usage of each socket address (protocol/network > address/port) is normally permitted. : make_sock: could not bind to > address [::]:9356 no listening sockets available, shutting down Unable to > open logs" > > Does somebody know what is the problem. > > > > > Thanks and Regards, > Ashwani Sharma > Mob: +91+9916454843 > Off: +91-80-26265053 > > > > -----Original Message----- > From: Rodent of Unusual Size [mailto:coar@apache.org] > Sent: Thursday, January 17, 2008 10:17 AM > To: Apache HTTP server developers > Subject: [STATUS] (httpd-2.0) Wed Jan 16 23:46:53 2008 > > > APACHE 2.0 STATUS: > -*-text-*- > Last modified at [$Date: 2008-01-10 11:27:21 -0500 (Thu, 10 Jan 2008) $] > > > The current version of this file can be found at: > > > * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS > > > Documentation status is maintained seperately and can be found at: > > > * docs/STATUS in this source tree, or > * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS > > > Consult the following STATUS files for information on related projects: > > > * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS > * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS > > > Consult the trunk/ for all new development and documentation efforts: > > > * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS > * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS > > > > Release history: > > > 2.0.63 : Tagged January 10, 2008. > 2.0.62 : Tagged January 4, 2008. Not released. > 2.0.61 : Released September 7, 2007. > 2.0.60 : Tagged August 10, 2007, not released. > 2.0.59 : released July 28, 2006 as GA. > 2.0.58 : released May 1, 2006 as GA. > 2.0.57 : tagged April 19, 2006, not released. > 2.0.56 : tagged April 16, 2006, not released. > 2.0.55 : released October 16, 2005 as GA. > 2.0.54 : released April 17, 2005 as GA. > 2.0.53 : released February 7, 2005 as GA. > 2.0.52 : released September 28, 2004 as GA. > 2.0.51 : released September 15, 2004 as GA. > 2.0.50 : released June 30, 2004 as GA. > 2.0.49 : released March 19, 2004 as GA. > 2.0.48 : released October 29, 2003 as GA. > 2.0.47 : released July 09, 2003 as GA. > 2.0.46 : released May 28, 2003 as GA. > 2.0.45 : released April 1, 2003 as GA. > 2.0.44 : released January 20, 2003 as GA. > 2.0.43 : released October 3, 2002 as GA. > 2.0.42 : released September 24, 2002 as GA. > 2.0.41 : rolled September 16, 2002. not released. > 2.0.40 : released August 9, 2002 as GA. > 2.0.39 : released June 17, 2002 as GA. > 2.0.38 : rolled June 16, 2002. not released. > 2.0.37 : rolled June 11, 2002. not released. > 2.0.36 : released May 6, 2002 as GA. > 2.0.35 : released April 5, 2002 as GA. > 2.0.34 : tagged March 26, 2002. > 2.0.33 : tagged March 6, 2002. not released. > 2.0.32 : released Feburary 16, 2002 as beta. > 2.0.31 : rolled Feburary 1, 2002. not released. > 2.0.30 : tagged January 8, 2002. not rolled. > 2.0.29 : tagged November 27, 2001. not rolled. > 2.0.28 : released November 13, 2001 as beta. > 2.0.27 : rolled November 6, 2001 > 2.0.26 : tagged October 16, 2001. not rolled. > 2.0.25 : rolled August 29, 2001 > 2.0.24 : rolled August 18, 2001 > 2.0.23 : rolled August 9, 2001 > 2.0.22 : rolled July 29, 2001 > 2.0.21 : rolled July 20, 2001 > 2.0.20 : rolled July 8, 2001 > 2.0.19 : rolled June 27, 2001 > 2.0.18 : rolled May 18, 2001 > 2.0.17 : rolled April 17, 2001 > 2.0.16 : rolled April 4, 2001 > 2.0.15 : rolled March 21, 2001 > 2.0.14 : rolled March 7, 2001 > 2.0a9 : released December 12, 2000 > 2.0a8 : released November 20, 2000 > 2.0a7 : released October 8, 2000 > 2.0a6 : released August 18, 2000 > 2.0a5 : released August 4, 2000 > 2.0a4 : released June 7, 2000 > 2.0a3 : released April 28, 2000 > 2.0a2 : released March 31, 2000 > 2.0a1 : released March 10, 2000 > > > > Contributors looking for a mission: > > > * Just do an egrep on "TODO" or "XXX" in the source. > > > * Review the bug database at: http://issues.apache.org/bugzilla/ > > > * Review the "PatchAvailable" bugs in the bug database: > > > > http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=A > SSIG > NED&bug_status=REOPENED&product=Apache+httpd-2.0&keywords=PatchAvailable > > > After testing, you can append a comment saying "Reviewed and tested". > > > * Open bugs in the bug database. > > > > CURRENT RELEASE NOTES: > > > * Forward binary compatibility is expected of Apache 2.0.x releases, such > that no MMN major number changes will occur. Such changes can only be > made in the trunk. > > * All commits to branches/2.0.x must be reflected in SVN trunk, > as well, if they apply. Logical progression is commit to trunk, get > feedback and votes on list or in STATUS, then merge into branches/2.2.x, > and finally merge into branches/2.0.x, as applicable. > > > RELEASE SHOWSTOPPERS: > > > PATCHES ACCEPTED TO BACKPORT FROM TRUNK: > [ start all new proposals below, under PATCHES PROPOSED. ] > > > PATCHES PROPOSED TO BACKPORT FROM TRUNK: > [ please place SVN revisions from trunk here, so it is easy to > identify exactly what the proposed changes are! Add all new proposals to > the end of this list. ] > > * Backport 327179; PR 31226; allow ap_add_output_filters_by_type to > handle proxied requests. Basic tests by jorton and [rpluem] show that > this works, nobody can actually remember why this limitation was introduced > at all (r94028) and the mailing list archives also gave no hint. > http://svn.apache.org/viewvc?view=rev&revision=327179 > +0: covener, wrowe > do we need to make people opt-in for this behavior to backport it to 2.0.x? > What mechanism? > > > * Backport 164538: add ap_vhost_iterate_given_conn(). > Trunk version of patch: > http://svn.apache.org/viewvc?view=rev&revision=164538 > Backport version for 2.0.x of patch: > > > http://people.apache.org/~fuankg/diffs/httpd-2.0.x-ap_vhost_iterate_given > _con > n.diff +1: fuankg, wrowe > > > PATCHES TO BACKPORT THAT ARE ON HOLD OR NOT GOING ANYWHERE SOON: > > > *) mod_headers: Support {...}s tag for SSL variable lookup. > http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff > +1: jorton, trawick > nd: two comments: > (1) is the use of APR_ASCII_* ebcdic-safe? I.e. shouldn't we use the > native chars here and it will be converted later? (I'm not sure) jorton: I > have no idea, let an EBCDIC-er complain if it breaks? trawick: seems that > '\r' and '\n' are the better chars to check > for; this is not raw data read from the network (or directly from SSL) but > instead it is either protocol data that has already been converted to the > native charset or it is other data which was created inside the server in > the native charset (2) I'd put out (null) only if val is NULL, not if it's > empty. jorton: ssl_var_lookup() returns "" in place of NULL, that was > really a deliberate choice... but maybe you're right. > > > *) Provide TLS/SSL upgrade functionality in mod_ssl allowing an unsecure > connection to be upgraded to a secure connection upon request by the > client. The full patch is available at http://www.apache.org/~bnicholes/ > as well as a test client tlsupgrade.c. This functionality is mainly used by > IPP clients today. > modules/ssl/mod_ssl.c: r1.75, r1.97, r1.100 > modules/ssl/mod_ssl.h: r1.123 > modules/ssl/ssl_engine_config.c: r1.71, r1.90 > modules/ssl/ssl_engine_init.c: r1.107, r1.126 > modules/ssl/ssl_engine_io.c: r1.102, r1.124 > modules/ssl/ssl_engine_kernel.c: r1.83, r1.105, r1.108 > modules/ssl/ssl_util.c: r1.36 > modules/ssl/ssl_private.h: r1.2 > +1: bnicholes, wrowe > -0: jerenkrantz (should wait for 2.2) > -0: pquerna (2.2) > -0: jorton (msgid <20040305083540.GA24529@redhat.com>) > > > > *) Replace some of the mutex locking in the worker MPM with > atomic operations for higher concurrency. server/mpm/worker/fdqueue.c 1.24, > 1.25 > +1: brianp, ianh, jjclar > trawick: Doesn't this make Apache 2.0.next slower except > when the right atomic operations are available/ implemented? (Due to > under-the-covers mutex operations when the dummy atomics are used?) > pquerna: Has anyone tested the performance differences > for different platforms? At this point I would favour waiting for 2.2. -0: > stoddard (at least until the performance implications are clarified) > > *) Allow mod_dav to do weak entity comparison functions. > modules/dav/main/util.c: r1.45 > [ This one is under review. Don't merge. ] > +1: > > > *) mod_negotiation: parse quality values independent from > the current locale and level values as integers. PR 17564. (essentially: > get a rid of atof()) (2.0 + 1.3) modules/mappers/mod_negotiation.c: r1.114 > +1: nd > We need to decide what happens with unparsable qvalues. RFC 2616 > states that q defaults to 1. (see 14.1 - 14.4). So should wrong qvalues be > returned as 1.0 or 0.0 (as atof() did)? 1.0: nd > 0.0: jim (a default != an "errored" value) > > > *) Keep the same SSLMutex for the lifetime of the parent process > (instead of having children using different mutexes and failing > to lock the session cache across restarts.) New patch forthcoming - > JimJag's changes make the merge ugly. > +1: wrowe > +1 (concept): jim (final vote when the patch is available) > > > *) Fix the SSLMutex config parser so that all 'mechanisms' can take > a filename, even if ignored, and they are rooted to the full path to the > server (except for posixsem locks). This allows a very cross-platform > default:logs/ssl_mutex to be used everywhere. Also > eliminates the '.pid' suffix so that the name given is the name. Allows > Win32 and other non-unicies to use named locks. > New patch forthcoming - JimJag's changes make the merge ugly. > +1: wrowe > +1 (concept): jim (final vote when the patch is available) > > > *) mod_ssl: Drop SSL_EXPERIMENTAL_ENGINE test in favor of testing for the > ENGINE_init() function in config.m4, and use HAVE_ENGINE_INIT instead. > wrowe notes that this feature is a noop until configured with SSLEngine. > http://www.apache.org/~wrowe/have_engine_init.patch for a clean 2.0 > patch. modules/ssl/README 1.40 modules/ssl/config.m4 1.14 > modules/ssl/mod_ssl.c 1.79 modules/ssl/mod_ssl.h 1.135 > modules/ssl/ssl_engine_config.c 1.78 modules/ssl/ssl_engine_init.c 1.113 > modules/ssl/ssl_toolkit_compat.c 1.33 +0: wrowe {Pending research into how > to get AC to use -lsockets et. al., shows breakage on Solaris which can't > -lcrypto -lssl > without the extra pkgconfig/openssl.pc Libs: * foo } > > *) mod_ssl: fix a link failure when the openssl-engine libraries are > present but the engine headers are missing. modules/ssl/mod_ssl.c: r1.87 > modules/ssl/mod_ssl.h: r1.139 > modules/ssl/ssl_engine_config.c: r1.82 > PREREQ: Blow away of SSL_EXPERIMENTAL_ENGINE (see above) > +1: jwoolley, trawick, jim, jerenkrantz > > > *) When UseCanonicalName is set to OFF, allow ap_get_server_port to > check r->connection->local_addr->port before defaulting to server->port or > ap_default_port() server/core.c r1.247 +1: bnicholes, jim, wrowe > 0: nd, jerenkrantz > nd: can the local_addr->port ever be 0? > bnicholes response: I couldn't tell you for sure if local_addr->port could > be 0. But it makes sense that if it were then Apache wouldn't be > listening on any port so it wouldn't matter anyway. nd replies: But if it > can't be 0 the alternatives thereafter make no sense anymore, right? jim > proposes: UseCanonicalName Client directive > which implements this, keeping UseCanonicalName Off "as is". > > > *) ThreadStackSize for Win32 and threaded MPMs > trawick will eventually put together a patch for httpd 2.0.next +1 concept: > trawick, nd, stoddard, wrowe > > *) don't propagate input headers describing a body to a GET subrequest > with no body http://svn.apache.org/viewcvs?view=rev&rev=158798 > http://svn.apache.org/viewcvs?view=rev&rev=159410 > http://svn.apache.org/viewcvs?view=rev&rev=160573 > +1: gregames, wrowe (provided this is applied to ALL subreq types!) > -1: jerenkrantz (read_length isn't a sufficient check to see if a body > is present in the request; presence of T-E and C-L in the headers is the > correct flag.) gregames: addressed jerenkrantz' objection in rev 160573 > wrowe: this has a negative impact on modules who wish to 'inspect' > the headers, e.g. an xml transformation affected by the query string or > request POST args. The right solution is adopt apreq, providing an API > for filters to participate in POST bodies. gregames: this does not affect > POSTs. the affected function helps > create a GET subrequest with no body and is unprepared to deal with > subrequest bodies. any modules or applications wishing to inspect headers > will in fact work better because the headers will reflect reality. wrowe: > I've reconsidered - the simple fact is that subrequests > don't have a good mechanism to 'share' the input body with the main > request, and it's gotta be up to the main request to handle the input > body. If the module wants to use apreq-provided data, then it's going to > have to ask apreq for the data instead of looking at the headers. For > that matter, why are subreq's even propogating POST or other non-GET > types? It seems that almost any subreq should be handled as a GET in 2.0. > > > *) Reverse Proxy fixes: bug and Cookie support > Patch is at > http://people.apache.org/~colm/httpd-2.0-reverse-proxy-cookie.patch > and is in production with Clients. +1: niq, wrowe > wrowe adds; looks good, no way to apply this without a minor bump > > CURRENT VOTES: > > > *) httpd-std.conf and friends; > > > a) httpd-std.conf should be tailored by install (from src or binbuild) > even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, > Ken, wrowe, jwoolley, jim, nd, > erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs, > note that win32 installer creates just that file (.default.conf rather > than .conf.default so that win32 can recognize .conf files as text > configuration files.) > > c) tailored httpd-std.conf should be installed to sysconfdir/examples or > manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), > erikabele > > *) If the parent process dies, should the remaining child processes > "gracefully" self-terminate. Or maybe we should make it a runtime > option, or have a concept of 2 parent processes (one being a "hot spare"). > See: Message-ID: <3C58232C.FE91F19F@Golux.Com> > > > Self-destruct: Ken, Martin > Not self-destruct: BrianP, Ian, Cliff, BillS > Make it runtime configurable: Aaron, Justin, wrowe, rederpj, jim, nd > > > /* The below was a concept on *how* to handle the problem */ > Have 2 parents: +1: jim > -1: Justin, wrowe, rederpj, nd > +0: Martin (while standing by, could it do > something useful?) > > *) Make the worker MPM the default MPM for threaded Unix boxes. > +1: Justin, Ian, Cliff, BillS, striker > +0: BrianP, Aaron (mutex contention is looking better with the > latest code, let's continue tuning and testing), rederpj, jim -0: Lars, > wrowe (let's make this defacto for the 2.2 release.), nd (for 2.0) > > > RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: > > > * There is a bug in how we sort some hooks, at least the pre-config > hook. The first time we call the hooks, they are in the correct order, but > the second time, we don't sort them correctly. Currently, the > modules/http/config.m4 file has been renamed to modules/http/config2.m4 to > work around this problem, it should moved back when this is fixed. > > OtherBill offers that this is a SERIOUS problem. We do not sort > correctly by the ordering arguments passed to the register hook functions. > This was proven when I reordered the open_logs hook > to attempt to open the error logs prior to the access logs. Possibly the > entire sorting code needs to be refactored. > > * pipes deadlock on all platforms with limited pipe buffers (e.g. both > Linux and Win32, as opposed to only Win32 on 1.3). The right solution > is either GStein's proposal for a "CGI Brigade", or OtherBill's proposal for > "Poll Buckets" for "Polling Filter Chains". Or perhaps both :-) > > > * All handlers should always send content down even if r->header_only > is set. If not, it means that the HEAD requests don't generate the same > headers as a GET which is wrong. > > * HP/UX 10.20: compile breakage in APR. Looks like it should be easy > to fix, probably just some extraneous #include's that are fouling things > up. PR: 9457 > Jeff: See my reply and patch in the PR (and previous commit to > stop using "pipe" as a field name). If patch is committed, we should be > okay. I'll wait to see if the user tests the patch. Update by Jeff > 20020722: I got an account on HP 10.20. It looks > like some of the APR thread detection is screwed up. If we find pthread.h > but we can't compile the pthread test program we still think we can use > threads. For that reason, the patch I posted to the PR won't work as-is > since a failed compile of the test program means nothing. > > * exec cmd and suexec arg-passing enhancements > Status: Patches proposed > Message-ID: <20020526041748.A29148@prodigy.Redbrick.DCU.IE> > (see the "proc.patch" and "suexec-shell.patch" links in this message) > > > * The 2.0.36 worker MPM graceless shutdown changes work but are > a bit clunky on some platforms; eg, on Linux, the loop to join each worker > thread seems to hang, and the parent ends up killing off the child with > SIGKILL. But at least it shuts down. > > > * --enable-mods-shared="foo1 foo2" is busted on Darwin. Pier > posted a patch (Message-ID: ). > > * We do not properly substitute the prefix-variables in the configuration > scripts or generated-configs. (i.e. if sysconfdir is etc, httpd-std.conf > points to conf.) > > * If any request gets through ap_process_request_internal() and is > scheduled to be served by the core handler, without a flag that this > r->filename was tested by dir/file_walk, we need to 500 at the very end of > the ap_process_request_internal() processing so sub_req-esters know this > request cannot be run. This provides authors of older modules better > compatibility, while still improving the security and robustness of 2.0. > > Status: still need to decide where this goes, OtherBill comments... > Message-ID: <065701c14526$495203b0$96c0b0d0@roweclan.net> > [Deleted comments regarding the ap_run_handler phase, as irrelevant > as BillS points out that "common case will be caught in default_handler > already (with the r->finfo.filetype == 0 check)" and the issue is > detecting this -before- we try to run the req.] > > gregames says: can this happen somehow without a broken module being > involved? If not, why waste cycles trying to defend against potential > broken modules? It seems futile. wrowe counters: no, it shouldn't happen > unless the module is broken. But the right answer is to fail the request > up-front in dir/file walk if the path was entirely invalid; and we can't > do that either UNTIL 2.1 or we break modules that haven't hooked > map_to_storage. > > * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me > how the Perchild MPM should be re-written. It hasn't worked correctly > since filters were added because it wasn't possible to get the content > that had already been written and the socket at the same time. This mode > lets us do that, so the MPM can be fixed. > > * htpasswd blindly processes the file you give it, and does no > sanity checking before totally corrupting whatever file it was you thought > you had. It should check the input file and bail if it finds non-comment > lines that do not contain exactly 1 ':' character. > Message-ID: <20020217150457.A31632@clove.org> > > > * Can a static httpd be built reliably? > Message-ID: <20020207142751.T31582@clove.org> > > > * [Ken] Test suite failures: > o worker is also failing some of the 'cgi' subtests (see > ): > Justin says: "Worker should be fine and passes httpd-test here. > I think it's a perl or a httpd-test problem." > > > * Usage of APR_BRIGADE_NORMALIZE in core_input_filter should be > removed if possible. Message-ID: > > Jeff wonders if we still care about this. It is no longer an > API issue but simply an extra trip through the brigade. > > > * The Add...Filter and Set...Filter directives do not allow the > administrator to order filters, beyond the order of filename (mime) > extensions. It isn't clear if Set...Filter(s) should be inserted before > or after the Add...Filter(s) which are ordered by sequence of filename > extensions. At minimum, some sort of +-[0-10] syntax seems like a nice > solution. See ROADMAP. > > * Get perchild to work on platforms other than Linux. This > will require a portable mechanism to pass data and file/socket descriptors > between vhost child groups. An API was proposed on dev@apr: Message-ID: > <20020111115006.K1529@clove.org> > > > * Try to get libtool inter-library dependency code working on AIX. > Message-ID: > > > Justin says: If we get it working on AIX, we can enable this > on all platforms and clean up our build system somewhat. Jeff says: I > thought I tested a patch for you sometime in January that you were going > to commit within a few days. > > * Handling of %2f in URIs. Currently both 1.3 and 2.0 > completely disallow %2f in the request URI path (see ap_unescape_url() in > util.c). It's permitted and passed through in the query string, however. > Roy says the > original reason for disallowing it, from five years ago, was to protect CGI > scripts that applied PATH_INFO to a filesystem location and which might be > tricked by ..%2f..%2f(...). We *should* allow path-info of the > form 'http://foo.com/index.cgi/path/to/path%2finfo'. Since we've revamped a > lot of our processing of path segments, it would be nice to allow this, or > at least allow it conditionally with a directive. > > OtherBill adds that %2f as the SECOND character of a multibyte > sequence causes the request to fail! This happens notably in the ja-jis > encoding. > > OtherBill is -0.5 for even considering this until 2.2 because > it removes some protection we provided to third party modules that would > mysteriously 'evaporate', exposing potential holes in security. Putting > this change into 2.1 development now (with strong warnings!) will give > authors a chance to vet their code. > > * There is increasing demand from module writers for an API > that will allow them to control the server � la apachectl. Reasons include > sole-function servers that need to die if an external dependency (e.g., a > database) fails, et cetera. Perhaps something in the (ever more abused) > scoreboard? > > On the other hand, we already have a pipe that goes between > parent and child for graceful shutdown events, along with an API that can be > used to send a message down that pipe. In threaded MPMs, it is easy > enough to make that one pipe be used for graceful and graceless events, > and it is also easy to open that pipe to both parent and child for > writing. Then we just need to figure out how to do graceless on > non-threaded MPMs. > > * Win32: Rotatelogs sometimes is not terminated when Apache > goes down hard. FirstBill was looking at possibly tracking the > child's-child processes in the parent process. stoddard: Shared scoreboard > might offer a good way for the parent to keep track of 'other child' > processes and whack them if the child goes down. Other thoughts on walking > the process chain using the NT kernel have also been proposed on APR. > > * Eliminate unnecessary creation of pipes in mod_cgid > > > * Combine log_child and piped_log_spawn. Clean up http_log.c. > Common logging API. > > > * There are still a number of places in the code where we are > losing error status (i.e. throwing away the error returned by a system call > and replacing it with a generic error code) > > * Mass vhosting version of suEXEC. > > > * All DBMs suffer from confusion in support/dbmmanage (perl script) since > > > the dbmmanage employs the first-matched dbm format. This is not > necessarily the library that Apache was built with. Aught to rewrite > dbmmanage upon installation to bin/ with the proper library for > predictable mod_auth_dbm administration. Questions; htdbm exists, time to > kill dbmmanage, or does it remain useful as a perl dbm management example? > If we keep it, > do we address the issue above? March discussion summary; we are missing > group support. With that added to trunk, this script will go away. It > will remain in 2.0 based on our versioning approach. > > * Integrate mod_dav. > Some additional items remaining: > - case_preserved_filename stuff > (use the new canonical name stuff?) > - find a new home for ap_text(_header) > - is it possible to remove the DAV: namespace stuff from util_xml? > > > * ap_core_translate() and its use by mod_mmap_static and mod_file_cache > are a bit wonky. The function should probably be exposed as a utility > function (such as ap_translate_url2fs() or ap_validate_fs_url() or > something). Another approach would be a new hook phase after "translate" > which would allow the module to munge what the translation has decided to > do. Status: Greg +1 (volunteers) > > > * Explore use of a post-config hook for the code in http_main.c which > calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and ap_sort_hooks() > [to reduce the logic in main()] > > > * read the config tree just once, and process N times (as necessary) > OtherBill adds that the 'good' solution of three passes against the > config tree within one read is the better solution, but breaks many > modules. Best left for 2.2? -0.5: OtherBill > > > * (possibly) use UUIDs in mod_unique_id and/or mod_usertrack > > > * (possibly) port the bug fix for PR 6942 (segv when LoadModule is put > into a VirtualHost container) to 2.0. > > * shift stuff to mod_core.h > > > * callers of ap_run_create_request() should check the return value > for failure (Doug volunteers) > > * Win32: Get Apache working on Windows 95/98. The following work > (at least) needs to be done: > - Document warning that OSR2 is required (for Crypt functions, in > rand.c, at least.) This could be resolved with an SSL library, or > randomization in APR itself. - Bring the Win9xConHook.dll from 1.3 into > 2.0 (no sense till it > actually works) and add in a splash of Win9x service code. > > * Fix the worker MPM to use POD to kill child processes instead > of ap_os_killpg, regardless of how they should die. > > * Scoreboard structures could be changed in the future such that > proper alignment is not maintained, leading to segfaults on some systems. > Cliff posted a patch to deal with this issue but > later recanted. See this message to dev@apr.apache.org: Message-ID: > .cs.virginia.edu> > > > * ap_discard_request should be converted to use the bucket API > directly rather than waste cycles copying buffers with the old API. > > * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a > sigwaiting thread. We need to work around this, perhaps unless there is > hope soon for a fixed glibc. > > > EXPERIMENTAL MODULES: > > > mod_auth_ldap/util_ldap: > * General stabilization and testing > > > * Fix the shared memory cache > > > > > DISCLAIMER: > This message (including attachment if any) is confidential and may be > privileged. If you have received this message by mistake please notify > the sender by return e-mail and delete this message from your system. Any > unauthorized use or dissemination of this message in whole or in part is > strictly prohibited. E-mail may contain viruses. Before opening > attachments please check them for viruses and defects. While MindTree > Consulting Limited (MindTree) has put in place checks to minimize the > risks, MindTree will not be responsible for any viruses or defects or any > forwarded attachments emanating either from within MindTree or outside. > Please note that e-mails are susceptible to change and MindTree shall not > be liable for any improper, untimely or incomplete transmission. MindTree > reserves the right to monitor and review the content of all messages sent > to or from MindTree e-mail address. Messages sent to or from this e-mail > address may be stored on the MindTree e-mail system or else where. >