[STATUS] (httpd-trunk) Wed Jan 2 23:49:40 2008
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2007-12-03 15:06:37 -0500 (Mon, 03 Dec 2007) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/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/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
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:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
After testing, you can append a comment saying "Reviewed and tested".
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* 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: <[EMAIL PROTECTED]>
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, 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, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for *2.4*?
wrowe: Replies "yes"
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr->main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see "MUST" v.s. "SHOULD" v.s. "MAY"
out of this list, without reviewing them individually.
* There is a bug in how we sort some hooks, at least the pre-config
hook. The first time we call the hooks,
[STATUS] (httpd-2.2) Wed Jan 2 23:47:16 2008
APACHE 2.2 STATUS: -*-text-*-
Last modified at [$Date: 2008-01-02 16:56:28 -0500 (Wed, 02 Jan 2008) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.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/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.2.7 : In development. Jim intends to T&R on Dec 29/30.
2.2.6 : Released September 7, 2007.
2.2.5 : Tagged August 10, 2007, not released.
2.2.4 : Released on January 9, 2007 as GA.
2.2.3 : Released on July 28, 2006 as GA.
2.2.2 : Released on May 1, 2006 as GA.
2.2.1 : Tagged on April 1, 2006, not released.
2.2.0 : Released on December 1, 2005 as GA.
2.1.10 : Tagged on November 19, 2005, not released.
2.1.9 : Released on November 5, 2005 as beta.
2.1.8 : Released on October 1, 2005 as beta.
2.1.7 : Released on September 12, 2005 as beta.
2.1.6 : Released on June 27, 2005 as alpha.
2.1.5 : Tagged on June 17, 2005.
2.1.4 : not released.
2.1.3 : Released on February 22, 2005 as alpha.
2.1.2 : Released on December 8, 2004 as alpha.
2.1.1 : Released on November 19, 2004 as alpha.
2.1.0 : not released.
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:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&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.2.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.2.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, as applicable.
RELEASE SHOWSTOPPERS:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
[ New proposals should be added at the end of the list ]
* mod_proxy: Support variable interpolation in reverse proxy configuration
(revised proposal dealing with wrowe's concerns).
trunk:
http://svn.apache.org/viewvc?view=rev&revision=421686 (code)
http://svn.apache.org/viewvc?view=rev&revision=422178 (code)
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?r1=420990&r2=421725
(docs)
http://svn.apache.org/viewvc?view=rev&revision=589371 (code+docs)
2.2.x:
http://people.apache.org/~niq/proxy-interp.patch
rpluem says: Please add the documentation to your 2.2.x version of your
patch and a minor bump (changes to public mod_proxy.h) and
assume you are +1 to your own proposal.
niq says: I'll attend to that. As regards vote, I'm +1 on the proposal,
but -0 on including this as a new feature in 2.2.7.
Better IMHO to separate releasing it from the many bugfixes
in 2.2.7 mod_proxy. Hence +1 for 2.2.8.
* configure / install: Make https port configurable.
Trunk version of patch:
http://svn.apache.org/viewvc?rev=606316&view=rev
http://svn.apache.org/viewvc?rev=606806&view=rev
Backport version for 2.2.x of patch:
http://people.apache.org/~fuankg/diffs/sslport.diff
+1: fuankg, wrowe
wrowe notes; Win32 is already ready for this, and there's no rush
to push this into the immediate next-release.
* mod_ssl: Add server name indication (RFC 4366) support (PR 34607).
Trunk version of patch:
http://svn.apache.org/viewvc?view=rev&revision=606190
Backport version for 2.2.x of patch:
http://people.apache.org/~fuankg/diffs/httpd-2.2.x-sni.diff
+1: fuankg
+0: like ssl upgrade of 2.2, perhaps this is a good reason to bring
[STATUS] (httpd-2.0) Wed Jan 2 23:46:40 2008
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2008-01-02 14:29:59 -0500 (Wed, 02 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.62 : In maintenance. Jim intends to T&R on Dec 29/30. 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=ASSIGNED&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 archive
[VOTE] initial release of httpd-mod_ftp-0.9.1
mod_ftp fans; We seem to have identified and solved most post 0.9.0 candidate issues, so it's time for another try. Please fetch up the newly prepared httpd-mod_ftp-0.9.1.tar.gz, or the win32/netware/os2 suitable package httpd-mod_ftp-0.9.1-crlf.zip (and their md5/asc sigs) from: http://httpd.apache.org/dev/dist/mod_ftp/ review, take it for a spin, and cast your choice [ ] -1 for any release of 0.9.1 [ ] +1 to release as 0.9.1-alpha [ ] +1 to release as 0.9.1-beta [ ] +1 to release as 0.9.1-beta, and ready to tag GA (1.0.0) See http://svn.apache.org/repos/asf/httpd/mod_ftp/tags/0.9.1/STATUS-FTP identifying several issues (I don't plan to vote for better than -beta just yet). Supporting -beta means +1 to -alpha instead if that's the majority opinion. For getting started, http://httpd.apache.org/mod_ftp/ which has links to all the various documentation. I haven't finished the implementation of Makefile.win-ftp just yet, and didn't want to hold up the release any more for just that, but docs on compiling for win32 are also in README-FTP. Bill
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 08:57 PM, Jim Jagielski wrote: > FWIW, STATUS on the 2.x branches is cleaned up in anticipation > of the T&R (there are no open patches for 1.3, afaik). > > If you haven't already, I encourage everyone to 'svn up' and > at least run some prelim tests before I do the actual T&R. > I've been working on getting my old Blade (Sol8) up and > running (something's happened to it since I last booted > it up) and test there (as well as on OS X and SUSE) before > I tag. So it would be useful to get some prelim feedback that > we are ready for a tag if others can test. > > SuSE 10.2 32 Bit: All litmus tests passed for WebDAV. RedHat AS4 64 Bit: 2.0.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 (1 subtest UNEXPECTEDLY SUCCEEDED), 16 tests and 25 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2790 subtests failed, 99.93% okay. No regression. 2.2.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 9 tests and 18 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2807 subtests failed, 99.93% okay. No regression. Solaris 9: 2.2.x: My perl test kit is incomplete, but as far as I can tell no regressions could be found. Solaris 10: 2.2.x: My perl test kit is incomplete, but as far as I can tell no regressions could be found. But there was a problem with the _default_ setting for a virtual host. I am not sure so far if this is my config or if there is something else going wrong on Solaris 10. I will investigate tomorrow. My Solaris boxes are to0 slow to get test results for both 2.0.x and 2.2.x in time, but given the fact that the changes for 2.0.x are small compared to 2.2.x I only tested 2.2.x. Regards Rüdiger
Re: Interfacing with mod_negotiation
Am Mittwoch, den 02.01.2008, 20:52 + schrieb Nick Kew: > On Wed, 02 Jan 2008 21:42:43 +0100 > Joachim Zobel <[EMAIL PROTECTED]> wrote: > > > There is probably some grand unified approach ahead, with filter > > layers between VFSes that besides the usual filter stuff do URL > > rewriting. Such an approach needs to be very well specified to keep > > it simple enough to be usable. > > That sounds more a 2.4 thing than a 2.2.x incremental upgrade. Thinking about it the idea is to have pairs of input and output filters that are layered. Response Request - | A | || | | | V| - | A | || | | | V| - | <-- | - But thats beyond 2.4 and I am not really in a position to make propositions. > If you were about to propose an API for mod_negotiation, I'd > encourage you to go ahead, at least in outline. It should be a > useful input to future designs, whether or not it has the capacity > to stand alone. I will add an interface that suits my needs. It should not be too hard to generalize it to content negotiation, but can only test it for language negotiation. Sincerely, Joachim
Low-hanging fruit in 2.2.x/STATUS
A gentle reminder, the mod_deflate and mod_dav backports aren't marked as showstoppers, but fix serious bugs. The mod_deflate proposal seems to me particularly low-hanging fruit. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
Ruediger Pluem wrote: First results for SuSE 10.2: 2.2.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 7 tests and 18 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2841 subtests failed, 99.93% okay. But this is no regression. Agreed, but the patch is out there awaiting one more review (and Joe who wrote the patch hasn't chimed in, while I and Rudiger have). So it could be considered if one more reviews it. (I had cast this yesterday, but didn't commit it all in one go, because it would have made the status commit more confusing. Then I just forgot to add it.) Bill
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 08:57 PM, Jim Jagielski wrote: > FWIW, STATUS on the 2.x branches is cleaned up in anticipation > of the T&R (there are no open patches for 1.3, afaik). FWIW, the reason that caused Nick to veto on 2.2.x is still there on 2.0.x, so I guess it would be good if you could give it the missing vote and backport it. > > If you haven't already, I encourage everyone to 'svn up' and > at least run some prelim tests before I do the actual T&R. > I've been working on getting my old Blade (Sol8) up and > running (something's happened to it since I last booted > it up) and test there (as well as on OS X and SUSE) before > I tag. So it would be useful to get some prelim feedback that > we are ready for a tag if others can test. > First results for SuSE 10.2: 2.2.x: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 7 tests and 18 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2841 subtests failed, 99.93% okay. But this is no regression. 2.0.x Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ssl/pr43738.t42 50.00% 2 4 (1 subtest UNEXPECTEDLY SUCCEEDED), 15 tests and 25 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 2/2816 subtests failed, 99.93% okay. But this is no regression. I try to get some more results in the next hour so stay tuned. Regards Rüdiger
Re: Interfacing with mod_negotiation
On Wed, 02 Jan 2008 21:42:43 +0100 Joachim Zobel <[EMAIL PROTECTED]> wrote: > There is probably some grand unified approach ahead, with filter > layers between VFSes that besides the usual filter stuff do URL > rewriting. Such an approach needs to be very well specified to keep > it simple enough to be usable. That sounds more a 2.4 thing than a 2.2.x incremental upgrade. If you were about to propose an API for mod_negotiation, I'd encourage you to go ahead, at least in outline. It should be a useful input to future designs, whether or not it has the capacity to stand alone. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Interfacing with mod_negotiation
Am Mittwoch, den 02.01.2008, 11:52 -0600 schrieb William A. Rowe, Jr.: > Joachim Zobel wrote: > > > > I want to say "Dear mod_negotiation, I offer the following language > > variants (for the current request). Which one do you choose?". > Wondering if this is worth a great deal of time until we define the VFS > in less APR'ish, less filesystem'ish patterns. I did not know about the VFS idea until know. Do you have a rough estimate when this will be implemented. (Of course I need the interface now :) > With a robust VFS for httpd, your provider could register the corresponding > content for a request, and negotiation would query VFS providers of both > multiview matches, type-maps, and your i18n. > WDYT? This would do. I had in fact already checked that mod_negotiation is actually doing file system calls hoping it might do a sub request for the type map. There is probably some grand unified approach ahead, with filter layers between VFSes that besides the usual filter stuff do URL rewriting. Such an approach needs to be very well specified to keep it simple enough to be usable. Sincerely, Joachim
Re: 64 bit Apache 2.2.4 on windows getting crashed
Hi, Like wrowe said... if it only happens with the module its mostlikely the module and not httpd (or my binary of httpd in this case). Although I've seen this before. The binaries on blackdot are compiled with visual studio 2005 and link to MSVCR80.dll, if the module is compiled against an other version it may give problems but not always (go figure) so if the module is indeed compiled for 64-bit with MSVC8 (aka visual studio 2005) and it still give problems its most likely the module. Kind regards --- Jorge Schrauwen Webmaster Blackdot.be On 1/2/08, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Renu Tiwari wrote: > > > The issue is when Apache is configured with a thirdparty module (64 bit > > as well) > > Well, which module probably makes a difference, and if the crash isn't > present *without* this module, you should be contacting the author of > the module, not httpd. > > > and is started the error is shown in event viewer as:- > > > > */Faulting application httpd.exe, version 2.2.3.0, faulting module > > abc_xyz.dll, version 6.0.513.383, fault address 0x000ec417./* > > That means nothing, since we know nothing of abc_xyz.dll, we can't > give you any clues what it might mean. > > http://httpd.apache.org/dev/debugging.html has information about > capturing stack backtraces to determine what function crashed, but > only if you have access to the .pdb diagnostic files ***for the > exact binaries you are running***. The symbols/ directory here > under /dist/httpd/binaries/win32/ would only apply to the binary > distributions in that directory. Sorry we can't help you more on > this issue, either. > > -- ~Jorge
Re: time for 1.3.40 and 2.2.7 ?
FWIW, STATUS on the 2.x branches is cleaned up in anticipation of the T&R (there are no open patches for 1.3, afaik). If you haven't already, I encourage everyone to 'svn up' and at least run some prelim tests before I do the actual T&R. I've been working on getting my old Blade (Sol8) up and running (something's happened to it since I last booted it up) and test there (as well as on OS X and SUSE) before I tag. So it would be useful to get some prelim feedback that we are ready for a tag if others can test.
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 05:35 PM, Jim Jagielski wrote: > Now that I am really back, I'd like to reboot the intent to > T&R all three. 2.2 has a current show-stopper however, with a veto > upon the patch by Nick. BTW: We have the same situation for 2.0.x. Only Nick did not put his veto in the STATUS file in this case. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 07:04 PM, Jim Jagielski wrote: > > On Jan 2, 2008, at 12:25 PM, Nick Kew wrote: > >> On Wed, 2 Jan 2008 11:56:23 -0500 >> Jim Jagielski <[EMAIL PROTECTED]> wrote: >> >>> Yes, I saw that, but I wanted to dig deeper and read his Email >>> on why he didn't like it... Until that's resolved, the SS >>> still exists (though with a caveat) >> >> In summary, I don't think that patch should spill outside mod_proxy_ftp. >> Putting it on the mod_proxy config, and hence involving changes to >> mod_proxy.h API and ap_mmn, seems like superfluous complexity/bloat. >> Especially when most mod_proxy users won't be requiring mod_proxy_ftp. >> >> But that's not a veto, just a -0. >> > > And a valid point... So far we have not put any configuration directives into mod_proxy_* even if they are specifc to a mod_proxy_* module (AllowCONNECT comes to mind). I do not say that this is correct, but I created my patch based on this and this seems to me a broader discussion that IMHO should not prevent us from releasing. Regards Rüdiger
Re: time for 1.3.40 and 2.2.7 ?
On Jan 2, 2008, at 12:25 PM, Nick Kew wrote: On Wed, 2 Jan 2008 11:56:23 -0500 Jim Jagielski <[EMAIL PROTECTED]> wrote: Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Until that's resolved, the SS still exists (though with a caveat) In summary, I don't think that patch should spill outside mod_proxy_ftp. Putting it on the mod_proxy config, and hence involving changes to mod_proxy.h API and ap_mmn, seems like superfluous complexity/bloat. Especially when most mod_proxy users won't be requiring mod_proxy_ftp. But that's not a veto, just a -0. And a valid point...
Re: Interfacing with mod_negotiation
Joachim Zobel wrote: For my module mod_i18n I would need an interface to content negotiation. I want to say "Dear mod_negotiation, I offer the following language variants (for the current request). Which one do you choose?". By now the only way to do this is to put variant files or a type map in the file system and do sub requests. Such an interface could be a mod_negotiation.h with a few optional functions, but there may be other ways (notes?). I am willing to do the necessary implementation, if this has a chance to be accepted. Wondering if this is worth a great deal of time until we define the VFS in less APR'ish, less filesystem'ish patterns. With a robust VFS for httpd, your provider could register the corresponding content for a request, and negotiation would query VFS providers of both multiview matches, type-maps, and your i18n. WDYT?
Re: time for 1.3.40 and 2.2.7 ?
Jim Jagielski wrote: Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Well, he wanted a patch for a narrowly defined mod_proxy_ftp-specific directive context, but offered a patch to apply a server_rec, while Rudiger's patch is against the dir_rec which is much more appropriate. AIUI he questioned the need to change the general mod_proxy directive configuration structures for a mod_proxy_ftp specific directive. That said, I don't see the issue, think it could be useful to other proxy intermediaries, so let's just go with Rudiger's. Bill
Re: 64 bit Apache 2.2.4 on windows getting crashed
Renu Tiwari wrote: The issue is when Apache is configured with a thirdparty module (64 bit as well) Well, which module probably makes a difference, and if the crash isn't present *without* this module, you should be contacting the author of the module, not httpd. and is started the error is shown in event viewer as:- */Faulting application httpd.exe, version 2.2.3.0, faulting module abc_xyz.dll, version 6.0.513.383, fault address 0x000ec417./* That means nothing, since we know nothing of abc_xyz.dll, we can't give you any clues what it might mean. http://httpd.apache.org/dev/debugging.html has information about capturing stack backtraces to determine what function crashed, but only if you have access to the .pdb diagnostic files ***for the exact binaries you are running***. The symbols/ directory here under /dist/httpd/binaries/win32/ would only apply to the binary distributions in that directory. Sorry we can't help you more on this issue, either.
Interfacing with mod_negotiation
Hi. For my module mod_i18n I would need an interface to content negotiation. I want to say "Dear mod_negotiation, I offer the following language variants (for the current request). Which one do you choose?". By now the only way to do this is to put variant files or a type map in the file system and do sub requests. Such an interface could be a mod_negotiation.h with a few optional functions, but there may be other ways (notes?). I am willing to do the necessary implementation, if this has a chance to be accepted. Sincerely, Joachim See http://www.heute-morgen.de/modules/mod_i18n/ on details about mod_i18n.
Re: time for 1.3.40 and 2.2.7 ?
On Wed, 2 Jan 2008 11:56:23 -0500 Jim Jagielski <[EMAIL PROTECTED]> wrote: > Yes, I saw that, but I wanted to dig deeper and read his Email > on why he didn't like it... Until that's resolved, the SS > still exists (though with a caveat) In summary, I don't think that patch should spill outside mod_proxy_ftp. Putting it on the mod_proxy config, and hence involving changes to mod_proxy.h API and ap_mmn, seems like superfluous complexity/bloat. Especially when most mod_proxy users won't be requiring mod_proxy_ftp. But that's not a veto, just a -0. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: time for 1.3.40 and 2.2.7 ?
On Jan 2, 2008, at 11:49 AM, Ruediger Pluem wrote: On 01/02/2008 05:35 PM, Jim Jagielski wrote: Now that I am really back, I'd like to reboot the intent to T&R all three. 2.2 has a current show-stopper however, with a veto upon the patch by Nick. You can solve this veto. Just vote for the vetoed patch plus for * mod_proxy_ftp: Introduce the ProxyFtpDirCharset directive, allowing the administrator to identify a default, or specific servers or paths which list their contents in other-than ISO-8859-1 charset (e.g. utf-8). [Ruediger Pluem] This makes Nick's veto void. Yes, I saw that, but I wanted to dig deeper and read his Email on why he didn't like it... Until that's resolved, the SS still exists (though with a caveat)
Re: time for 1.3.40 and 2.2.7 ?
On 01/02/2008 05:35 PM, Jim Jagielski wrote: > Now that I am really back, I'd like to reboot the intent to > T&R all three. 2.2 has a current show-stopper however, with a veto > upon the patch by Nick. You can solve this veto. Just vote for the vetoed patch plus for * mod_proxy_ftp: Introduce the ProxyFtpDirCharset directive, allowing the administrator to identify a default, or specific servers or paths which list their contents in other-than ISO-8859-1 charset (e.g. utf-8). [Ruediger Pluem] This makes Nick's veto void. Regards Rüdiger
Re: svn commit: r606190 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_toolkit_compat.h
Joe, many thanks for your review and valuable comments, first off! As
the person who contributed to the original SNI patch (authored by Peter
Sylvester/EdelWeb), I'll try to address your questions to the best of my
knowledge/ability.
An updated version of the patch (based on Guenter's latest version), is
attached to this message, in two versions: first against r606189 (the
last w/o any SNI related code) and second, against the current trunk
version. I'm grateful for comments, hints about flaws in my reasoning /
incorrect assumptions / omissions, or even objections, if there are.
> My main comment: it's not obvious to me how this actually does what it
> needs to. The issue with getting true SNI support is that the hostname
> sent in the ClientHello must cause a change to the selection of
> r->server early enough to ensure that any security policy specified in
> the vhost configuration is applied correctly (e.g. SSLVerifyClient) -
> not merely selection of the correct SSL_CTX (and hence server cert).
That's correct. However, choosing the appropriate r->server is mainly
handled by ap_read_request() in protocol.c, fortunately: specifically,
ap_read_request() calls ap_update_vhost_from_headers() to select the
right virtual host.
> I can't see how this patch achieves that. Any clues?
If the request includes a Host: header (which results in r->hostname
being set), then everything is fine as soon as the headers have been
read (i.e. before ssl_hook_ReadReq is called, and of course before
ssl_hook_Access checks for directory-specific access restrictions). We
"only" need to make sure that the correct SSL context (and hence the
right server cert) is selected while the TLS handshake takes place.
> Has a configuration
> with an SSLVerifyClient specified in the named vhost been tested?
Yes, and one specific configuration actually made me tweak the code in
the servername callback further: when modifying the SSL connection,
OpenSSL's SSL_set_SSL_CTX() will only adjust the server cert from the
context, but not additional settings like verify_mode and the verify
callback. These are relevant when SSLVerifyClient is configured at the
*per-server* context (i.e. at the vhost level), and the previous version
of the patch failed to enforce such a configuration, at least in cases
where SSLVerifyClient for the first (=default) VirtualHost was different
than for any subsequent VirtualHosts.
Per-directory SSLVerifyClient settings don't suffer from this problem
(as the correct vhost is selected before ssl_hook_Access is called),
these are enforced by triggering a renegotiation, if needed.
When speaking of renegotiating (but not related to SSLVerifyClient
specifically), note that I removed this code from ssl_hook_Access:
> - * We will force a renegotiation if we switch to another virtualhost.
> - */
> -if (r->hostname && !SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name)) {
> -if (ssl_set_vhost_ctx(ssl, r->hostname) && ctx !=
> SSL_get_SSL_CTX(ssl))
> -renegotiate = TRUE;
> -}
This applied to connections from clients which did not send an SNI
extension; renegotiating here doesn't make much sense to me since these
clients already received a (possibly) wrong certificate, so the mismatch
has already happened.
On the other hand, I've added some code to ssl_hook_ReadReq which deals
with the case where the client supplies an SNI extension but doesn't
send a Host: header (which is probably rare, but anyway):
> +if (!r->hostname &&
> +(servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name))) {
> +/* Use the SNI extension as the hostname if no Host: header was sent
> */
> +r->hostname = apr_pstrdup(r->pool, servername);
> +ap_update_vhost_from_headers(r);
> +}
In reply to your further comments (unless addressed by Guenter already):
> 3) Calling an env var "SSL_TLS_..." is redundant; why is an extra env
> var necessary here anyway?
It adds a couple of useful options when dealing with SSL requests:
* in a CGI application, you can programmatically determine if the client
supplied an SNI extension (and possibly redirect the user, or point
him to further information)
* you can log this information (LogFormat and "%{SSL_TLS_SNI}e" as the
parameter), which allows to gather statistics about the percentage
of SNI capable clients your site has, e.g.
* you can use this information in mod_rewrite rules, e.g. for
rewriting requests based on the absence of an SNI extension (such as
'RewriteCond %{SSL:SSL_TLS_SNI} =""' - note that I had to add support
for this in ssl_engine_vars.c, this didn't work so far)
I agree that "SSL_TLS_" is somewhat redundant, but on the other hand
"SSL_" seems to be the proper prefix for all mod_ssl related variables,
and using "SSL_SNI" only might lead to the conclusion that SNI is also
relates to pure SSLv2/v3 connections.
> 4) Why is it desirable to send a fatal TLS alert if no vhost is found
> matchi
Re: time for 1.3.40 and 2.2.7 ?
Now that I am really back, I'd like to reboot the intent to T&R all three. 2.2 has a current show-stopper however, with a veto upon the patch by Nick.
64 bit Apache 2.2.4 on windows getting crashed
Hi All, We have installed 64 bit Apache 2.2.4 on windows. We downloaded the installer from http://www.blackdot.be/?inc=apache/binaries The issue is when Apache is configured with a thirdparty module (64 bit as well) and is started the error is shown in event viewer as:- Faulting application httpd.exe, version 2.2.3.0, faulting module abc_xyz.dll, version 6.0.513.383, fault address 0x000ec417. We have checked in Apache's error logs, no error is present there. Please suggest. Thanks CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
