Re: Bug 35083 - SSL error trapping
Hi Joe
1. The current idea is to trap validation-related errors, like
certificate expiration/revocation.
Shouldn't we also trap negotiation errors, like incompatible
ciphersuites and protocols between browser and server ?
Maybe other ones ?
I would not try to solve everything at once; just concentrate on the one
problem of handling verification errors.
OK, although it may be a step back if we decide to trap other stuff later.
For example, negotiation errors will not set the variable SSL_CLIENT_VERIFY.
I really wonder if we are not better to not use existing variable and
directives - so adding a new variable like SSL_STATUS.
Also, comparing strings is not very pretty (what if OpenSSL error
message changes, even slightly); I would recommend an error code.
2. Recommendations are to use one directive to relax the check on
certificates (or on ciphersuites, ...), and other ones to trap errors by
checking environment variables and redirect the 403 errors to a specific
page.
a. Doesn't this introduce a security risk, in case the check on
certificates is relaxed and the other directives are not set (or changed) ?
This is against the principle of secure by installation ...
I don't see a problem here. The proposal was to add a directive to
relax/restrict the set of verification errors which are considered
acceptable for an SSLVerifyClient optional configuration.
That directive will then control whether or not the 403 is returned.
aybe I misunderstood; I thought you were suggesting that the 403 had to
be managed in the conf file with SSLRequire.
So, we relax the check with SSLVerifyClient optional_..., then we
redirect to 403 with SSLRequire.
In this case, if we ever break the SSLRequire (you know administrators
;-), then all certificates are accepted.
I understand it works, but isn't that too complex for a normal admin,
and potentially dangerous ?
b. This solution would redirect all errors to the same page.
Isn't it better to trap the error and redirect to a specific
(customisable) page ?
Note that this trapping could be implemented in a separate module.
I'm not sure what else is needed here. It should already be possible to
access the verification error string e.g. from mod_rewrite using
%{SSL:SSL_CLIENT_VERIFY}. I'd guess this could be done during the
handling of the 403 and could allow a rewrite to a custom URI - or is
there something which prevents that?
You're right, although I would recommend (cf. 1) a new variable
containing a return code.
Marc
FW: unsubscribe
Learn more about Chase Paymentech Solutions,LLC payment processing services at www.chasepaymentech.com. THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer.
Re: mod_authn_dbd and apr_password_validate
On Mon, Jan 08, 2007 at 09:10:52PM +, Nick Kew wrote:
On Mon, 8 Jan 2007 16:08:51 +
Patrick Welche [EMAIL PROTECTED] wrote:
so what sort of password does apr_password_validate accept?
Those created with htpasswd is a simple answer.
Would the following patch be acceptable? (So that one has a clue on how
to populate the database.)
Cheers,
Patrick
Index: mod_authn_dbd.xml
===
--- mod_authn_dbd.xml (revision 494830)
+++ mod_authn_dbd.xml (working copy)
@@ -111,6 +111,17 @@
example
AuthDBDUserPWQuery SELECT password FROM authn WHERE username = %s
/example
+pIf using codeDBDriver pgsql/code and given a PostgreSQL
+database with the pgcrypto contrib module loaded, password
+encryptions accepted by mod_authn_db include
+code
+crypt(plaintext_password,gen_salt('md5'))
+/code
+and
+code
+'{SHA}'||encode(digest(plaintext_password,'sha1'),'base64')
+/code
+/p
pIf httpd was built against apr v1.3.0 or higher, any additional
columns specified in the select statement will be inserted into
the environment with the name codeAUTHENTICATE_lt;COLUMNgt;/code.
mod_mbox patches
Hi!
Here are some patches for mod_mbox to correcly display binary mime-parts.
Please review;
--- module-2.0/mod_mbox.h.orig Tue Jan 9 15:06:24 2007
+++ module-2.0/mod_mbox.h Tue Jan 9 15:06:01 2007
@@ -130,6 +130,7 @@
mbox_mime_message_t *mbox_mime_decode_multipart(apr_pool_t *p, char *body,
char *ct, mbox_cte_e cte,
char *boundary);
+char *mbox_mime_decode_body_bin(apr_pool_t *p, mbox_cte_e cte, char *body, apr_size_t len, apr_size_t *out_len);
char *mbox_mime_decode_body(apr_pool_t *p, mbox_cte_e cte, char *body, apr_size_t len);
char *mbox_mime_get_body(apr_pool_t *p, mbox_mime_message_t *m);
void mbox_mime_display_static_structure(request_rec *r, mbox_mime_message_t *m,
--- module-2.0/mod_mbox_mime.c.orig Tue Jan 9 15:02:01 2007
+++ module-2.0/mod_mbox_mime.c Tue Jan 9 15:05:10 2007
@@ -290,7 +290,7 @@
}
/* Decode a MIME part body, according to its CTE. */
-char *mbox_mime_decode_body(apr_pool_t *p, mbox_cte_e cte, char *body, apr_size_t len)
+char *mbox_mime_decode_body_bin(apr_pool_t *p, mbox_cte_e cte, char *body, apr_size_t len, apr_size_t *out_len)
{
char *new_body;
@@ -310,9 +310,14 @@
}
new_body[len] = 0;
+if (out_len) (*out_len) = len;
return new_body;
}
+char *mbox_mime_decode_body(apr_pool_t *p, mbox_cte_e cte, char *body, apr_size_t len)
+{
+ return mbox_mime_decode_body_bin(p, cte, body, len, NULL);
+}
/* This function returns the relevant MIME part from a message. For
* the moment, it just returns the first text/ MIME part available.
--- module-2.0/mod_mbox_out.c.orig Tue Jan 9 15:10:13 2007
+++ module-2.0/mod_mbox_out.c Tue Jan 9 15:09:47 2007
@@ -1029,14 +1029,15 @@
if (mime_part-body_len 0) {
const char* pdata;
-/* : Not binary data safe? */
+apr_size_t out_len;
mime_part-body[mime_part-body_len] = 0;
-pdata = mbox_mime_decode_body(r-pool,
+pdata = mbox_mime_decode_body_bin(r-pool,
mime_part-cte,
mime_part-body,
- mime_part-body_len);
+ mime_part-body_len,
+ out_len);
if (pdata != NULL) {
-ap_rputs(pdata, r);
+ap_rwrite(pdata, out_len, r);
}
}
[Announce] Apache HTTP Server 2.2.4 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache HTTP Server 2.2.4 Released The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.2.4 of the Apache HTTP Server (Apache). This version of Apache is principally a bugfix release. We consider this release to be the best version of Apache available, and encourage users of all prior versions to upgrade. Apache HTTP Server 2.2.4 is available for download from: http://httpd.apache.org/download.cgi Apache 2.2 offers numerous enhancements, improvements, and performance boosts over the 2.0 codebase. For an overview of new features introduced since 2.0 please see: http://httpd.apache.org/docs/2.2/new_features_2_2.html Please see the CHANGES_2.2 file, linked from the download page, for a full list of changes. A summary of security vulnerabilities which were addressed in the previous 2.2.3 and earlier releases is available: http://httpd.apache.org/security/vulnerabilities_22.html Apache HTTP Server 1.3.37 and 2.0.59 legacy releases are also currently available. See the appropriate CHANGES from the url above. See the corresponding CHANGES files linked from the download page. The Apache HTTP Project developers strongly encourage all users to migrate to Apache 2.2, as only limited maintenance is performed on these legacy versions. This release includes the Apache Portable Runtime (APR) version 1.2.8 bundled with the tar and zip distributions. The APR libraries libapr and libaprutil (and on Win32, libapriconv) must all be updated to ensure binary compatibility and address many known platform bugs. This release builds on and extends the Apache 2.0 API. Modules written for Apache 2.0 will need to be recompiled in order to run with Apache 2.2, and require minimal or no source code changes. http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/VERSIONING When upgrading or installing this version of Apache, please bear in mind that if you intend to use Apache with one of the threaded MPMs (other than the Prefork MPM), you must ensure that any modules you will be using (and the libraries they depend on) are thread-safe. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRaVEufcTqHkQ/eB1AQL88Af7Bi5QMcTba30GCnmrINUdcqg/qyOq0J65 5pYTUO5rUl93e6xlN8nMBS+H/54JmJwieomCezhZYaaLbJ+9n/nWTdI5tuvcbLKf ApuFYT9pEqc/OAXelGUb9QdYD8IR0jjKpLz25nb4rJmOmP4SZMDEQFABk/VK+DS5 vtso09ii4drDfnU9yrmzA3ZJoperAMADejHCVDAf0a9pTD8cJGyRG+hxTj96DhfN xphY1JEOxRCAGLSrpp55LVe2m8YQ91ZYx5ll+yC5/vXlHXj8fdM3HHavFK9Bx2ez N52vqEexzele/1a3TCmHJp3i6zSgfAsVn4UWCIytyJEIfSptPMZQWg== =LvM+ -END PGP SIGNATURE-
Re: [VOTE] httpd-2.2.4 release candidate for review
William A. Rowe, Jr. wrote: http://httpd.apache.org/dev/dist/ will soon (within the hour, upon resync) contain the following tarballs for approval httpd-2.2.4.tar.bz2 [.asc|.md5] httpd-2.2.4.tar.gz [.asc|.md5] httpd-2.2.4-win32-src.zip [.asc|.md5] I counted 7+1, 0-1. Thanks everyone.
2.2.4 windows binary w/ssl?
I'd like to propose we ship apache_2.2.4-win32-x86-openssl-0.9.8d.msi with this release. Couple of notes... Roy has started the details spelled out at http://www.apache.org/dev/crypto.html and I'm certain he will complete them sometime shortly, here. That's a red flag that prevents us from making this available, even on /dev/dist/ for your evaluation. Trust that I will first upload the proposed package to /dev/dist/ for feedback before it lands in /dist/httpd/binaries/win32/. apache_2.2.4-win32-x86-ssl.msi was the anticipated name. The more I consider how tightly bound such a distribution is to openssl, and the version bound to the various security features in the corresponding release of openssl, the more I think we need an explicit package name. The zlib package used today is stock 1.2.3 with the /Oy- optimization override, to ensure we can read the Dr Watson backtrace for a crash report with or w/o the user deploying .pdb files. It adds .pdb generation (/Zi linked with the /debug /opt:ref flags) which adds no overhead to the binary, but creates a parallel .pdb file. The openssl package will be built also with /Oy- disable to ensure we can read backtraces (even more critical given how we hook into the module!) and also generating .pdb files. It will be configured no-mdc2 no-rc5 no-idea enable-zlib against the zlib package I cited above. (This is not zlib-dynamic!!! That would be a thread-unsafe choice :) Almost any stock build using openssl's own ms/ntdll.mak file will work to replace it, if the user chooses. Install path, like zlib, is private within Apache2\bin\ (that's an aspect of how binary search paths work on win32, where the lib\ directory isn't well suited for loadable libraries.) Note that the package then includes mod_ssl.so, and ab.exe compiled against openssl for https: stress measurement. It also includes openssl.exe for the generation of keys and certs. A final question for all, do we wish to install an arbitrary, on the fly self signed default.crt/default.key? Do we want to help them fill out the details or use stock details? Or do we want them to use openssl.exe to generate one for themselves?
Re: 2.2.4 windows binary w/ssl?
On 1/10/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: A final question for all, do we wish to install an arbitrary, on the fly self signed default.crt/default.key? Do we want to help them fill out the details or use stock details? Or do we want them to use openssl.exe to generate one for themselves? I'd prefer to just point them at the instructions for generating their own key rather than us distributing a 'fake' one. -- justin
Re: 2.2.4 windows binary w/ssl?
I think the MSI should autogenerate a self-signed cert at least (last thing we need is for people to deploy a static pre-distributed cert which would make it that much easier to do man-in-the-middle attacks). Would be great if the MSI had a choice to use an existing cert, or generate a new one with a user supplied DN (fill-in fields for CN, OU, O , L, ST, C), and generated a self-signed cert with that + a .csr for sending to a Trusted Third-Party for signing. Would also be great if there was some GUI for importing a signed cert post-install, similar to the IIS wizard, but that's probably pushing it. Just my $0.02, Issac William A. Rowe, Jr. wrote: A final question for all, do we wish to install an arbitrary, on the fly self signed default.crt/default.key? Do we want to help them fill out the details or use stock details? Or do we want them to use openssl.exe to generate one for themselves?
Re: 2.2.4 windows binary w/ssl?
Do note that not all users that will chose the SSL package will know how to correctly fill in the fields. My experience tells me if there is a package with XYZ and without most chose it with XYZ even if they don't need it. So if there is a dialog in the installer that would ask for the information... make sure there is lots of information available on what to enter! My 0,02 EUR Cent ;) On 1/10/07, Issac Goldstand [EMAIL PROTECTED] wrote: I think the MSI should autogenerate a self-signed cert at least (last thing we need is for people to deploy a static pre-distributed cert which would make it that much easier to do man-in-the-middle attacks). Would be great if the MSI had a choice to use an existing cert, or generate a new one with a user supplied DN (fill-in fields for CN, OU, O , L, ST, C), and generated a self-signed cert with that + a .csr for sending to a Trusted Third-Party for signing. Would also be great if there was some GUI for importing a signed cert post-install, similar to the IIS wizard, but that's probably pushing it. Just my $0.02, Issac William A. Rowe, Jr. wrote: A final question for all, do we wish to install an arbitrary, on the fly self signed default.crt/default.key? Do we want to help them fill out the details or use stock details? Or do we want them to use openssl.exe to generate one for themselves? -- ~Jorge
Re: 2.2.4 windows binary w/ssl?
Jorge Schrauwen wrote: Do note that not all users that will chose the SSL package will know how to correctly fill in the fields. s/not all/a small minority of/ They can't figure out what Domain Name means, let's be serious :) On 1/10/07, *Issac Goldstand* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think the MSI should autogenerate a self-signed cert at least (last thing we need is for people to deploy a static pre-distributed cert which would make it that much easier to do man-in-the-middle attacks). I agree, static keys are only for pure localhost-style examples, just a bad idea for something this flexible. As far as a default selfsigned cert, I was thinking of using the server name they filled in already as it stands, and let them replace it with a worthwhile one. Would be great if the MSI had a choice to use an existing cert, or generate a new one with a user supplied DN (fill-in fields for CN, OU, O , L, ST, C), and generated a self-signed cert with that + a .csr for sending to a Trusted Third-Party for signing. Would also be great if there was some GUI for importing a signed cert post-install, similar to the IIS wizard, but that's probably pushing it. Well, there are dozens of utilities out there that do that, I'm not compelled in the least to add it to the httpd package. Justin Erenkrantz wrote: I'd prefer to just point them at the instructions for generating their own key rather than us distributing a 'fake' one. -- justin ./configure; make; make install We don't deposit a certificate today for Unix. After considering this a bit more, I agree with jerenkrantz. At least, initially. I'd rather see something out the door, with all the appropriate comments in the user community of the best way (in their opinion) to proceed. Then if we really believe the server install should do something to either help deposit a cert/key for their server, or a post-install command should be provided for this purpose, then we should ensure win and unix are offering the exact same facility. Does this sound sane?
Re: 2.2.4 windows binary w/ssl?
On 1/10/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: Do note that not all users that will chose the SSL package will know how to correctly fill in the fields. s/not all/a small minority of/ Do not underestimate user stupidity ;) ok maybe the number won't be overly to large but I can sure see the post flooding in on the Apache BB's! They can't figure out what Domain Name means, let's be serious :) On 1/10/07, *Issac Goldstand* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think the MSI should autogenerate a self-signed cert at least (last thing we need is for people to deploy a static pre-distributed cert which would make it that much easier to do man-in-the-middle attacks). I agree, static keys are only for pure localhost-style examples, just a bad idea for something this flexible. As far as a default selfsigned cert, I was thinking of using the server name they filled in already as it stands, and let them replace it with a worthwhile one. Would be great if the MSI had a choice to use an existing cert, or generate a new one with a user supplied DN (fill-in fields for CN, OU, O , L, ST, C), and generated a self-signed cert with that + a .csr for sending to a Trusted Third-Party for signing. Would also be great if there was some GUI for importing a signed cert post-install, similar to the IIS wizard, but that's probably pushing it. Well, there are dozens of utilities out there that do that, I'm not compelled in the least to add it to the httpd package. Justin Erenkrantz wrote: I'd prefer to just point them at the instructions for generating their own key rather than us distributing a 'fake' one. -- justin ./configure; make; make install We don't deposit a certificate today for Unix. After considering this a bit more, I agree with jerenkrantz. True... if you don't enable mod_ssl by default and add a note in the conf file It should be rather safe to not include a cert. Pointing them to a docs or wiki guide/how to would be a good idea. At least, initially. I'd rather see something out the door, with all the appropriate comments in the user community of the best way (in their opinion) to proceed. Then if we really believe the server install should do something to either help deposit a cert/key for their server, or a post-install command should be provided for this purpose, then we should ensure win and unix are offering the exact same facility. Does this sound sane? Yes it does sound sane ;) -- ~Jorge
Re: 2.2.4 windows binary w/ssl?
On 01/10/2007 10:40 PM, William A. Rowe, Jr. wrote: Does this sound sane? +1 Regards Rüdiger
ap_get_module_config() questions...
Hi everyone, I have a couple quick questions regarding ap_get_module_config(). First, how do I return valuable information if there's a config error? For example, if my config has the directive MyFile conf/foo.txt and the file doesn't exist, how can I report this when I run httpd -t? Second, the documentation (er, at least http_config.h) suggest using r-per_dir_config or s-module_config for the conf vector (first arg). I can only get things to work if I pass cmd-server-module_config. Is this the same as s-module_config? Is this a coding blunder? Finally, I may need to access this 20K file several times per invocation. Is this a case where I'd want to mmap the file? Anyone got a code snippet that demonstrates this? Thanks. -- Drew
[STATUS] (httpd-2.0) Wed Jan 10 23:49:37 2007
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2007-01-05 22:48:09 -0500 (Fri, 05 Jan 2007) $] 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.60 : in maintenance 2.0.59 : tagged July 27, 2006 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=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=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. ] *) Reverse Proxy fixes: Location 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 *) Backport 102870; PR 17217; stop linking OpenSSL .so's to support/* binaries
[STATUS] (httpd-trunk) Wed Jan 10 23:49:08 2007
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
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=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=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-devm=105451701628081w=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-devm=105366252619530w=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.2?
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=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2keywords=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
