Re: GET request content and mod_python.publisher/psp.
On 03/04/2006, at 4:53 PM, Mike Looijmans wrote: My question is, should mod_python.publisher and mod_python.psp be enhanced and call req.discard_request_body() for a GET request to avoid the posibilities of any problems arising due to a client sending content for a GET request? -1 on that particular way of implementing it. If the GET request has a body, that body probably serves some purpose. The right thing to do for any handler that does not know how to handle the request is to return a 'bad request' error to the client. Just throwing away what is not understood is not very nice to developers and users - you'll get unexpected behaviour because the server is only handling a part of the request. The trouble here is of course that publisher or PSP cannot tell forehand that the handler will read the body data. So the only way to determine this is to have the handler handle the request, and after that, check if it did read all of the request. If not, you're too late to report this to the client, because the headers have already been sent out. Putting some message in an error log that no- one will ever read (in particular not the one who caused that problem) does not make sense either. To fix this, the handler should somehow advertise its capability to read the body. I guess you can't really solve the problem. Which is the lesser evil? Digging further, Apache will always ensure that ap_discard_request_body() is executed at the end of the request being processed, so there is no real problem to be solved. Although caution is good, I have read to much into the combination of the statements: The first step we take upon entering the handler() function is to call the discard_request_body() method. Unlike HTTP/1.0, where only POST and PUT requests may contain a request body, in HTTP/1.1 any method may include a body. We have no use for it, so we throw it away to avoid potential problems. and: * In HTTP/1.1, any method can have a body. However, most GET handlers * wouldn't know what to do with a request body if they received one. * This helper routine tests for and reads any message body in the request, * simply discarding whatever it receives. We need to do this because * failing to read the request body would cause it to be interpreted * as the next request on a persistent connection. The bit I was missing was that Apache calls the function already. :-) So, nothing to see, move along Graham
RE: mod_cgid not able to handle large POST request
when commented it uses DEFAULT_SOCKET /cgisock Rajesh R--This space intentionally left non-blank. From: pradeep kumar [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 11:28 AMTo: dev@httpd.apache.orgSubject: Re: mod_cgid not able to handle large POST request I don't have multiple instances of Apache. When I just use the standard httpd.conf with only this directive commeted out I get this error. There is no issue of multiple instances using the same Unix socket. How does the communication between the cgid deamon and httpd deamon happen when the Scriptsock directive is commented out. On 3/31/06, Jeff Trawick [EMAIL PROTECTED] wrote: On 3/31/06, pradeep kumar [EMAIL PROTECTED] wrote: One more detail. I get this error only on commenting out the Scriptsock directive. When I use this directive though I have no trouble in running the script.Is there more than one Apache instance with same ServerRoot, such that using the default ScriptSock results in multiple instances trying touse the same Unix socket?I assume you set Scriptsock to anon-default value?
Re: When did this break?
On Fri, Mar 31, 2006 at 03:23:11PM -0600, William Rowe wrote: It seems this can be trivially solved by ensuring we defer this test until after we invoke the sub-configure of apr and apr-util. The sufficient version test is currently only used if the sub-configure of ap[ru] is *not* invoked - when $apr_found is yes, not reconfig. --with-apr=srclib/apr actually treats the bundled sources like any external copy of APR, so must be already-configured at the time the httpd configure is run, AFAIK. If that's not happened, the apX-N-config file would not be found, so configure should fail earlier. What's really needed here is a --with-included-apr-type flag which forces use of the bundled sources over installed versions, rather than trying to overload --with-apr to do that. joe William A. Rowe, Jr. wrote: ./configure --with-apr=srclib/apr configure:5784: checking for APR version 1.2.0 or later conftest.c:20:25: apr_version.h: No such file or directory configure:5812: result: no configure:5818: error: APR version 1.2.0 or later is required This test is bogus because apr_version includes apr.h and that doesn't exist in a source-build tree. Why not test the file with awk? Bill . joe
Re: svn commit: r390922 - in /httpd/httpd/trunk: CHANGES server/core.c
[EMAIL PROTECTED] wrote: --- httpd/httpd/trunk/server/core.c (original) +++ httpd/httpd/trunk/server/core.c Sun Apr 2 16:36:27 2006 @@ -3596,6 +3596,20 @@ APR_BRIGADE_INSERT_TAIL(bb, e); return ap_pass_brigade(r-output_filters, bb); +status = ap_pass_brigade(r-output_filters, bb); Certainly we want to remove the 'return ap_pass_brigade' line... :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r391025 - /httpd/httpd/trunk/server/core.c
On 4/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jim Date: Mon Apr 3 05:10:22 2006 New Revision: 391025 URL: http://svn.apache.org/viewcvs?rev=391025view=rev Log: We actually want to reach the rest of the code :) Thanks for cleaning up after me!!!
Mod_proxy_http ProxyErrorOverride eating cookies
Hi,
The ProxyErrorOverride On setting is correctly catching the errors
from the (reverse) proxied server. Only, it overrides too much IMHO.
Right now it overrides anything that's not in the 2xx range, but I think
it should allow also the 3xx range for redirects etc.
A commonly used trick is to set a cookie with a 302 header so the
browser gets redirected to the page which needs the cookie. When using
ProxyErrorOverride, mod_proxy_http sets its own headers and the cookie
is lost.
The attached patch check not only for ap_is_HTTP_SUCCESS but also for
ap_is_HTTP_REDIRECT which should solve the problem.
Thanks,
Bart van der Schans
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-
[EMAIL PROTECTED] / http://www.hippo.nl
--
--- httpd-2.2.0-orig/modules/proxy/mod_proxy_http.c 2005-11-10
16:20:05.0 +0100
+++ httpd-2.2.0/modules/proxy/mod_proxy_http.c 2006-03-31 18:02:26.0
+0200
@@ -1447,7 +1447,7 @@
* if we are overriding the errors, we can't put the content
* of the page into the brigade
*/
-if (conf-error_override == 0 || ap_is_HTTP_SUCCESS(r-status)) {
+if (conf-error_override == 0 || ap_is_HTTP_SUCCESS(r-status) ||
ap_is_HTTP_REDIRECT(r-status)) {
/* read the body, pass it to the output filters */
apr_read_type_e mode = APR_NONBLOCK_READ;
int finish = FALSE;
@@ -1549,7 +1549,7 @@
if (conf-error_override) {
/* the code above this checks for 'OK' which is what the hook expects
*/
-if (ap_is_HTTP_SUCCESS(r-status))
+if (ap_is_HTTP_SUCCESS(r-status) || ap_is_HTTP_REDIRECT(r-status))
return OK;
else {
/* clear r-status for override error, otherwise ErrorDocument
Re: Mod_proxy_http ProxyErrorOverride eating cookies
-Ursprüngliche Nachricht- Von: Bart van der Schans Hi, The ProxyErrorOverride On setting is correctly catching the errors from the (reverse) proxied server. Only, it overrides too much IMHO. Right now it overrides anything that's not in the 2xx range, but I think it should allow also the 3xx range for redirects etc. I had a quick look into this and noticed the following: 1. It may make sense to add ap_is_HTTP_INFO to this also. 2. ProxyErrorOverride is currently only honoured by mod_proxy_http, mod_proxy_ajp ignores it. Is this intended? 3. This is a change in behaviour for people who use customized redirect pages for browsers that do not support redirects (are there any?) 4. 304 not modified responses from the backend are currently not supported without this patch. Thoughts? Regards Rüdiger
mod_http_proxy bug?
It looks like I'm getting some wierdness with http_proxy. it is not returning any error, but is giving back a 0 length bucket from apr_bucket_read when it should have some length. is there yet another way to check in a filter (ie, mod_cache stuff) if proxy had an error? doesn't look like it's getting bubbled up.. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Plüm wrote: -Ursprüngliche Nachricht- Von: Bart van der Schans Hi, The ProxyErrorOverride On setting is correctly catching the errors from the (reverse) proxied server. Only, it overrides too much IMHO. Right now it overrides anything that's not in the 2xx range, but I think it should allow also the 3xx range for redirects etc. I had a quick look into this and noticed the following: 1. It may make sense to add ap_is_HTTP_INFO to this also. Yes, that shounds like a good idea. 2. ProxyErrorOverride is currently only honoured by mod_proxy_http, mod_proxy_ajp ignores it. Is this intended? I don't have much experience with ajp, but being able to set a custom error is a good idea I think. 3. This is a change in behaviour for people who use customized redirect pages for browsers that do not support redirects (are there any?) Wouldn't that change from currently broken to working? 4. 304 not modified responses from the backend are currently not supported without this patch. I didn't actually tested that. Regards, Bart Thoughts? Regards Rüdiger -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
AW: mod_http_proxy bug?
-Ursprüngliche Nachricht- Von: Brian Akins It looks like I'm getting some wierdness with http_proxy. it is not returning any error, but is giving back a 0 length bucket from apr_bucket_read when it should have some length. This description requires some clarification IMO. Is this 0 length bucket really a data bucket? Is it the last bucket that comes thru your filter or do you see non zero length buckets afterwards for this request? is there yet another way to check in a filter (ie, mod_cache stuff) if proxy had an error? doesn't look like it's getting bubbled up.. Proxy sents up an error_bucket with HTTP_BAD_GATEWAY if the connection to the backend broke in the middle. Regards Rüdiger
Re: [VOTE] Release 2.2.1 as GA
On 4/1/2006 at 12:28 pm, in message [EMAIL PROTECTED], Paul Querna [EMAIL PROTECTED] wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Pau -1 NetWare Generating Release.o\Apache2_link.opt Linking Release.o/Apache2.nlm ### mwldnlm Linker Error: # Undefined symbol: apu_version_string in # main.o Errors caused tool to abort. gmake: *** [Release.o/Apache2.nlm] Error 1 Seems we have the same missing apu_version_string problem Brad
Re: When did this break?
On Mon, Apr 03, 2006 at 08:53:24AM +0100, Joe Orton wrote:
What's really needed here is a --with-included-apr-type flag which
forces use of the bundled sources over installed versions, rather than
trying to overload --with-apr to do that.
e.g. this, slightly hacky but does it solve the problem you were having?
Index: configure.in
===
--- configure.in(revision 388210)
+++ configure.in(working copy)
@@ -61,8 +61,16 @@
echo $ac_n ${nl}Configuring Apache Portable Runtime library ...${nl}
-APR_FIND_APR($srcdir/srclib/apr, ./srclib/apr, 1, 1)
+AC_ARG_WITH(included-apr,
+APACHE_HELP_STRING(--with-included-apr,Use bundled copies of APR/APR-Util))
+if test x$with_included_apr = xyes; then
+ apr_found=reconfig
+ apr_config=$srcdir/srclib/apr/apr-1-config
+else
+ APR_FIND_APR($srcdir/srclib/apr, ./srclib/apr, 1, 1)
+fi
+
if test $apr_found = no; then
AC_MSG_ERROR([APR not found. Please read the documentation.])
fi
@@ -89,7 +97,12 @@
echo $ac_n ${nl}Configuring Apache Portable Runtime Utility library...${nl}
-APR_FIND_APU($srcdir/srclib/apr-util, ./srclib/apr-util, 1, 1)
+if test x$with_included_apr = xyes; then
+ apu_found=reconfig
+ apu_config=${srcdir}/srclib/apr-util/apu-1-config
+else
+ APR_FIND_APU($srcdir/srclib/apr-util, ./srclib/apr-util, 1, 1)
+fi
if test $apu_found = no; then
AC_MSG_ERROR([APR-util not found. Please read the documentation.])
Re: [VOTE] Release 2.2.1 as GA
On 4/3/2006 at 8:54:29 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: On 4/1/2006 at 12:28 pm, in message [EMAIL PROTECTED], Paul Querna [EMAIL PROTECTED] wrote: 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: http://httpd.apache.org/dev/dist/ Please Test and Vote on releasing 2.2.1 as GA. MD5s: f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz Thanks, Pau -1 NetWare Generating Release.o\Apache2_link.opt Linking Release.o/Apache2.nlm ### mwldnlm Linker Error: # Undefined symbol: apu_version_string in # main.o Errors caused tool to abort. gmake: *** [Release.o/Apache2.nlm] Error 1 Seems we have the same missing apu_version_string problem Brad SVN rev. 391070 resolves the issue for NetWare. Brad
RFC: Protecting mod_ssl key with TPM
Here is a patch that adds a feature to allow the mod_ssl key to be bound to a
platform TPM (Trusted Platform Module described in specifications by the
Trusted Computing Group). This feature is desirable to protect the key
from being stolen by an attacker and used on another machine to spoof
the secure site. The feature works by encrypting the mod_ssl key with
an AES key which is then bound to a TPM and thus usable only on that
platform.
The tpm_unseal library and tpm_sealdata command for binding the key to
the TPM can be found at www.sourceforge.net/projects/trousers in the
tpm-tools package.
What do others think of this idea? Suggestions on the patch?
Thanks,
Kylie Hall
---
Index: modules/ssl/ssl_util_ssl.c
===
--- modules/ssl/ssl_util_ssl.c (revision 384633)
+++ modules/ssl/ssl_util_ssl.c (working copy)
@@ -1,6 +1,8 @@
/* Copyright 2001-2005 The Apache Software Foundation or its licensors, as
* applicable.
*
+ * TPMUNSEAL Portions Copyright (C) 2006 IBM Corporation
+ *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
@@ -25,6 +27,9 @@
*/
#include ssl_private.h
+#ifdef HAVE_TPMUNSEAL
+#include tpm_tools/tpm_unseal.h
+#endif
/* _
**
@@ -127,35 +132,49 @@
EVP_PKEY *SSL_read_PrivateKey(char* filename, EVP_PKEY **key,
modssl_read_bio_cb_fn *cb, void *s)
{
-EVP_PKEY *rc;
-BIO *bioS;
-BIO *bioF;
+EVP_PKEY *rc = NULL;
+BIO *bioS = NULL;
+BIO *bioF = NULL;
+#ifdef HAVE_TPMUNSEAL
+unsigned char *data = NULL;
+int data_len;
+int tpmRc = tpmUnsealFile(filename, data, data_len);
+
+if (tpmRc != 0) {
+ap_log_error(APLOG_MARK,
+ ((tpmRc == TPMSEAL_FILE_ERROR tpm_errno == ENOTSSHDR)
+ ? APLOG_DEBUG : APLOG_ERR), 0, s, %s,
+ tpmUnsealStrerror(tpmRc));
+}
+else {
+if ((bioS = BIO_new_mem_buf(data, data_len)) == NULL)
+return NULL;
+BIO_set_close(bioS, BIO_NOCLOSE);
+}
+#endif
+
+if (bioS == NULL (bioS = BIO_new_file(filename, r)) == NULL)
+return NULL;
+
/* 1. try PEM (= DER+Base64+headers) */
-if ((bioS=BIO_new_file(filename, r)) == NULL)
-return NULL;
rc = modssl_PEM_read_bio_PrivateKey(bioS, key, cb, s);
-BIO_free(bioS);
+BIO_reset(bioS);
if (rc == NULL) {
/* 2. try DER+Base64 */
-if ((bioS = BIO_new_file(filename, r)) == NULL)
-return NULL;
+if ((bioF = BIO_new(BIO_f_base64())) == NULL)
+goto out;
-if ((bioF = BIO_new(BIO_f_base64())) == NULL) {
-BIO_free(bioS);
-return NULL;
-}
-bioS = BIO_push(bioF, bioS);
-rc = d2i_PrivateKey_bio(bioS, NULL);
-BIO_free_all(bioS);
+BIO_push(bioF, bioS);
+rc = d2i_PrivateKey_bio(bioF, NULL);
+BIO_pop(bioF);
+BIO_free(bioF);
+BIO_reset(bioS);
if (rc == NULL) {
/* 3. try plain DER */
-if ((bioS = BIO_new_file(filename, r)) == NULL)
-return NULL;
rc = d2i_PrivateKey_bio(bioS, NULL);
-BIO_free(bioS);
}
}
if (rc != NULL key != NULL) {
@@ -163,6 +182,13 @@
EVP_PKEY_free(*key);
*key = rc;
}
+
+ out:
+#ifdef HAVE_TPMUNSEAL
+if (data)
+tpmUnsealShred(data, data_len);
+#endif
+BIO_free(bioS);
return rc;
}
Index: modules/ssl/config.m4
===
--- modules/ssl/config.m4 (revision 384633)
+++ modules/ssl/config.m4 (working copy)
@@ -12,6 +12,26 @@
dnl See the License for the specific language governing permissions and
dnl limitations under the License.
+AC_DEFUN([CHECK_TPMUNSEAL], [
+ AC_MSG_CHECKING(for tpm-tools unseal library)
+save_libs=$LIBS
+LIBS=$LIBS -ltpm_unseal
+AC_TRY_LINK(
+ [#include tpm_tools/tpm_unseal.h],
+ [tpmUnsealStrerror(0);],
+ [],
+ [tmp_no_message=failed to link with tpm_unseal library
+ ap_ssltk_ts=no])
+LIBS=$save_libs
+AC_MSG_RESULT($ap_ssltk_ts)
+if test x$ap_ssltk_ts = xno; then
+ AC_MSG_WARN(tpm_unseal support failed: $tmp_nomessage)
+else
+ APR_ADDTO(MOD_SSL_LDADD,[-ltpm_unseal])
+ AC_DEFINE(HAVE_TPMUNSEAL, 1, [Define if tpm_unseal support is enabled])
+fi
+])
+
AC_DEFUN([CHECK_DISTCACHE], [
AC_MSG_CHECKING(whether Distcache is required)
ap_ssltk_dc=no
@@ -117,6 +137,7 @@
APACHE_CHECK_SSL_TOOLKIT
APR_SETVAR(MOD_SSL_LDADD, [\$(SSL_LIBS)])
CHECK_DISTCACHE
+CHECK_TPMUNSEAL
if test x$enable_ssl = xshared; then
# The only symbol which needs to be exported is the module
# structure, so ask libtool
Re: svn commit: r391080 - in /httpd/mod_smtpd/trunk/src: Makefile.am smtp_bouncer.c smtp_protocol.c smtp_util.c
On 4/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
--- httpd/mod_smtpd/trunk/src/smtp_util.c (original)
+++ httpd/mod_smtpd/trunk/src/smtp_util.c Mon Apr 3 09:40:17 2006
@@ -76,15 +76,17 @@
smtpd_run_on_reset_envelope(scr);
smtpd_clear_envelope_rec(scr);
}
-
+#if 0
#include netinet/in.h
#include arpa/nameser.h
#include resolv.h
+#endif
SMTPD_DECLARE_NONSTD(apr_status_t)
smtpd_get_mailex(apr_pool_t *pool, /* out */ char **resolved_host,
char *original_host)
{
+#if 0
/* res_search hack, too dependent */
unsigned char buf[NS_PACKETSZ];
ns_msg handle;
@@ -130,6 +132,8 @@
ns_rr_rdata(rr) + 2,
*resolved_host,
MAXDNAME);
+#endif
+*resolved_host = apr_pstrdup(pool, original_host);
return APR_SUCCESS;
}
If you must #if 0 out code like this, at least leave some indication
of why it's been done. Ideally though, I'd suggest just removing it,
you can always get it back from the subversion repository if you need
it again later.
-garrett
apu_version mess
To resolve the problems we have with calling apu_version from httpd, we have three main options: [ ] Remove the new code that outputted the versions. [ ] Make the code only present on systems that didn't have a broken build. [ ] Wait for APR-Util 1.2.7 to be released. Votes/Thoughts? All of the options pretty much mean scraping the 2.2.1 release, and moving on to 2.2.2. Thanks, Paul
AW: apu_version mess
-Ursprüngliche Nachricht- Von: Paul Querna To resolve the problems we have with calling apu_version from httpd, we have three main options: [ ] Remove the new code that outputted the versions. [X] Make the code only present on systems that didn't have a broken build. [ ] Wait for APR-Util 1.2.7 to be released. Votes/Thoughts? All of the options pretty much mean scraping the 2.2.1 release, and moving on to 2.2.2. I think that this is wise anyway because I forgot to backport r379237. Meanwhile r379237 has been backported. Without this patch SSL to proxy backends do not work and nearly all ssl proxy tests from the test framework fail. Version numbers are cheap :-). Regards Rüdiger
Re: apu_version mess
Paul Querna wrote: To resolve the problems we have with calling apu_version from httpd, we have three main options: [ ] Remove the new code that outputted the versions. [ ] Make the code only present on systems that didn't have a broken build. [X] Wait for APR-Util 1.2.7 to be released. ... as a bugfix (configuration) release only, and quickly? yes. Votes/Thoughts? All of the options pretty much mean scraping the 2.2.1 release, and moving on to 2.2.2. Previous to 1.2.7 Win32 and Netware were borked. FYI I'm doing a fast delta on win32/unix (Brad, could you shoot me the
Re: apu_version mess
On 4/3/2006 at 11:38:28 am, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Paul Querna wrote: To resolve the problems we have with calling apu_version from httpd, we have three main options: [ ] Remove the new code that outputted the versions. [ ] Make the code only present on systems that didn't have a broken build. [X] Wait for APR-Util 1.2.7 to be released. ... as a bugfix (configuration) release only, and quickly? yes. Votes/Thoughts? All of the options pretty much mean scraping the 2.2.1 release, and moving on to 2.2.2. Previous to 1.2.7 Win32 and Netware were borked. FYI I'm doing a fast delta on win32/unix (Brad, could you shoot me th My vote would be first Wait for APR-Util 1.2.7 to be released if this can happen quickly. Even if the only difference between 1.2.6 and 1.2.7 is the apu_version_string() patch for Win32/NetWare. Otherwise I would go with Remove the new code that outputted the versions Brad
Re: [VOTE] Release 2.2.1 as GA
On 4/1/06, Steffen [EMAIL PROTECTED] wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 This is fixed on APR 0.9 / 1.2 branches and 1.3 trunk. Brad's fixed this on 1.2 branch and 1.3 trunk - and I have a pending request to him to ensure it's fixed on 0.9 branch as well. My thought is reroll aprutil, which i'll do tonight. The problem isn't with httpd; the problem's with the maintenance on two platforms, and that's what the release notes/CHANGES will say. Bill
Re: [VOTE] Release 2.2.1 as GA
So does that mean if one grabs the 2.2.1 tar ball one will not be able to build on Windows? If so, that's not a very compelling tarball for those needing to support Windows. If 2.2.1 is being labeled as non-GA already then that's quite appropriate, move on to 2.2.2 as soon as possible. 2.2.1 shouldn't be labeled as GA if it does not build on Windows as is, though. -- Jess Holle William A. Rowe, Jr. wrote: On 4/1/06, Steffen [EMAIL PROTECTED] wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 This is fixed on APR 0.9 / 1.2 branches and 1.3 trunk. Brad's fixed this on 1.2 branch and 1.3 trunk - and I have a pending request to him to ensure it's fixed on 0.9 branch as well. My thought is reroll aprutil, which i'll do tonight. The problem isn't with httpd; the problem's with the maintenance on two platforms, and that's what the release notes/CHANGES will say. Bill
Re: [VOTE] Release 2.2.1 as GA
Jess Holle wrote: So does that mean if one grabs the 2.2.1 tar ball one will not be able to build on Windows? Correct, but the 2.2.2 tarball will build on windows (with a bumped aprutil). That's why I think the concensus, between borked Win32/Netware and a missing proxy patch, is to reroll and get the 2.2.2 out immediately this week. Oh, my personal vote to the RM's tally is -1 (moving rapidly to 2.2.2). If so, that's not a very compelling tarball for those needing to support Windows. If 2.2.1 is being labeled as non-GA already then that's quite appropriate, move on to 2.2.2 as soon as possible. 2.2.1 shouldn't be labeled as GA if it does not build on Windows as is, though. 2.2.1 is labeled nothing right now, that's why the thread is [VOTE].
[PATCH] htdbm: warn crypt-enabled users that plaintext format won't work
Index: support/htdbm.c === --- support/htdbm.c (revision 390811) +++ support/htdbm.c (working copy) @@ -308,6 +308,10 @@ case ALG_PLAIN: /* XXX this len limitation is not in sync with any HTTPd len. */ apr_cpystrn(cpw,htdbm-userpass,sizeof(cpw)); +#if APR_HAVE_CRYPT_H +fprintf(stderr, Warning: Plain text passwords aren't supported by the +server on this platform!\n); +#endif break; #if APR_HAVE_CRYPT_H case ALG_CRYPT: FWIW, when you choose crypt() you see CRYPT is now deprecated, use MD5 instead! As I understand the plaintext password issue: In the database file, there are special denotations for md5 and sha1 password hashes, and if there is no denotation then the server expects (defaults to) crypt() format. But on Windows no crypt() function is available, so no denotation means plaintext format there. 1) design issue: file format doesn't have a delimeter for plain text, so a server on Unix has no way to support plaintext passwords 2) usability issue: htdbm doesn't warn users on platforms with crypt() that it is fruitless to specify plaintext format for password
Re: [PATCH] htdbm: warn crypt-enabled users that plaintext format won't work
Taking things one step further, sha1 is far preferred for cryptographic purposes these days than md5. Suppose its time to switch? Bill Jeff Trawick wrote: Index: support/htdbm.c === --- support/htdbm.c (revision 390811) +++ support/htdbm.c (working copy) @@ -308,6 +308,10 @@ case ALG_PLAIN: /* XXX this len limitation is not in sync with any HTTPd len. */ apr_cpystrn(cpw,htdbm-userpass,sizeof(cpw)); +#if APR_HAVE_CRYPT_H +fprintf(stderr, Warning: Plain text passwords aren't supported by the +server on this platform!\n); +#endif break; #if APR_HAVE_CRYPT_H case ALG_CRYPT: FWIW, when you choose crypt() you see CRYPT is now deprecated, use MD5 instead! As I understand the plaintext password issue: In the database file, there are special denotations for md5 and sha1 password hashes, and if there is no denotation then the server expects (defaults to) crypt() format. But on Windows no crypt() function is available, so no denotation means plaintext format there. 1) design issue: file format doesn't have a delimeter for plain text, so a server on Unix has no way to support plaintext passwords 2) usability issue: htdbm doesn't warn users on platforms with crypt() that it is fruitless to specify plaintext format for password
Re: prefork mpm in linux: ap_process_connection isn't called on connection
On Mar 31, 2006, at 6:42 AM, Jeff Trawick wrote: On 3/28/06, Rian A Hunter [EMAIL PROTECTED] wrote: On the httpd trunk in prefork.c ap_process_connection isn't called until there is data on the new connection (instead of just when a client connects). Is there a kernel accept filter enabled? No, it is a default clean install. Are you suggesting that for me to get the behavior I want that there should be one enabled? Rian
