Re: svn commit: r569204 - in /httpd/httpd/trunk/modules/experimental: config.m4 mod_rewrite_filter.c mod_sedfilter.c
Jim Jagielski wrote: On Aug 23, 2007, at 8:54 PM, [EMAIL PROTECTED] wrote: Author: wrowe Date: Thu Aug 23 17:54:15 2007 New Revision: 569204 URL: http://svn.apache.org/viewvc?rev=569204view=rev Log: SEDFILTER has several anomolies; first, it's not SED syntax, but more mod-rewrite like (and using the rewrite pcre parser). Secondly, 'FILTER' in the filter name is redundant. Simplify, by renaming this 'REWRITE' filter. IMO, changing this from sedfilter to mod_rewrite_filter actually is more confusing (or would be) to end users, since we have a mod_rewrite already. IMO mod_rewrite_content would be a better choice, esp if mod_rewrite was called mod_rewrite_url... Ack, I've heard that. Was seeking a name that might fit better, but I can certainly appreciate how this might be confusing. Plus, it doesn't deserve the swiss army knife stigma that mod_rewrite has. In any case, I don't feel strongly enough about it to do anymore than send this single post... Actually, please scroll down to the dialog, some good ideas down there. I'm only waiting for a couple people to agree on a name to adjust this once again :) Bill
Re: svn commit: r569204 - in /httpd/httpd/trunk/modules/experimental: config.m4 mod_rewrite_filter.c mod_sedfilter.c
Jim Jagielski wrote: Ruediger Pluem wrote: Roy T. Fielding wrote: or [*] mod_substitute [*] mod_substitute I like mod_substitute... (I thought filter was redundant *duck* :) ) So mod_substitute it is :) Fixing
Re: Most likely 1.3 1st then 2.x
Sander Temme wrote: We can even do the same for 2.0.x once we have our regression fixed, and then make a splash for all three when 2.2.x is done. 2.0 and 2.2 both have piped log issues. For 2.0 this is slightly more critical, we still invoke the log pipe app directly, and then pid_kill the thing on plog teardown. This means there is a lag between now-dead logger and new open_logs hook, which is especially uncool. On 2.2 it's not quite so bad, since we pid_kill bin/sh leaving bin/sh's invoked process running. r569535 doesn't quite clean on either 2.0 or 2.2, so I'll post up the link a bit later to tweaked patches.
Re: svn commit: r569938 - in /httpd/httpd/trunk/modules/ldap: util_ldap_cache.c util_ldap_cache_mgr.c
[EMAIL PROTECTED] wrote: Author: trawick Date: Sun Aug 26 17:53:41 2007 New Revision: 569938 URL: http://svn.apache.org/viewvc?rev=569938view=rev Log: better apr_ctime() usage (too bad it is apr_ctime_LEN instead of apr_ctime_SIZE) That's a great point; +1 to deprecating APR_CTIME_LEN for APR_CTIME_SIZE and documenting that its NULL terminated. Nice catches, thanks. Bill
Re: svn commit: r569947 - /httpd/httpd/branches/2.2.x/STATUS
Many thanks to Ruediger for reviewing 2.0 and 2.2 so far, and to both Jim and Jeff for their reviews of current/2.2 modern flavors. I could use a set of eyeballs on the final log.c patch for 2.2, and the patch set for our old 'n crusty 2.0. I'm especially interested if any Win32 folks want to take a peek at my suggested mpm_winnt change set before I commit it to 2.0. Holler if you are. There is a patch over at apr-1.x trunk waiting for comments so I can call 1.2 and 0.9 baked. Essentially, I've given up; Ryan and I had attempted to make Win32 inheritance behave as Unix fork() inheritance, and it just made zero sense and the end of the day. If you study mpm_winnt, we don't even open our listeners and mutexes as inherited; we start the process (suspended), duplicate the desired handles into the child process, and then send the child's handle id's down to it via the stdin channel. Sounds like unix domain sockets, eh? So the model didn't work, and for NT I propose to stop inheriting the handles other than stdin/out/err. Leave only the currently dup2()'ed handle as inherited, and temporarily uninherit even those, when they have been overridden. Why leave them inherited at all? For good old classic apps that still rely on classic inheritance. Since we can't do this in Win9x, there is a trivial patch that makes the problem of holding open the old error log go away there, too. --- server/log.c(revision 569931) +++ server/log.c(working copy) @@ -265,6 +265,10 @@ apr_proc_t *procnew; apr_file_t *errfile; +if (dummy_stderr) +if ((rc = apr_file_open_stderr(errfile, p)) == APR_SUCCESS) +apr_file_inherit_unset(errfile); + if (((rc = apr_procattr_create(procattr, p)) == APR_SUCCESS) ((rc = apr_procattr_cmdtype_set(procattr, APR_SHELLCMD_ENV)) == APR_SUCCESS) Essentially, before we play with proc_create, we tell apr that we don't want stderr ever inherited by any process, ever again. This is a noop on NT, and just forces stderr to be closed on fork before exec on unix (before, I trust, stdout replaces the stderr.) So on unix, it's also effectively a no-op. Something to ponder - I'm really not that motivated to apply this fix just for Win9x, but if people holler before we tag httpd again, I'll stand behind the patch. I don't know if it has any impact on the other implementations of apr_proc_create(). Bill [EMAIL PROTECTED] wrote: Author: wrowe Date: Sun Aug 26 18:24:43 2007 New Revision: 569947 URL: http://svn.apache.org/viewvc?rev=569947view=rev Log: Some final suggestions for 2.2.6 Modified: httpd/httpd/branches/2.2.x/STATUS Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=569947r1=569946r2=569947view=diff == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Sun Aug 26 18:24:43 2007 @@ -215,6 +215,25 @@ http://svn.apache.org/viewvc?view=revrevision=569622 +1: niq, rpluem +* log core: ensure we use a special pool for stderr logging, so that + the stderr channel remains valid from the time plog is destroyed, + until the time the open_logs hook is called again. [William Rowe] +http://svn.apache.org/viewvc?view=revrevision=569535 + Backported to 2.2; +http://people.apache.org/~wrowe/r569535-backport-2.2.patch + +1: wrowe + +* mod_ssl: Version reporting update; displays 'compiled against' + Apache and build-time SSL Library versions at loglevel [info], + while reporting the run-time SSL Library version in the server + info tags. Helps to identify a mod_ssl built against one flavor + of OpenSSL but running against another (also adds SSL-C version + number reporting.) [William Rowe] +http://svn.apache.org/viewvc?view=revrevision=520701 + Backported to 2.2; +http://people.apache.org/~wrowe/r520701-backport-2.2.patch + +1: wrowe +
Re: svn commit: r570074 - /httpd/httpd/branches/2.0.x/STATUS
[EMAIL PROTECTED] wrote: Modified: httpd/httpd/branches/2.0.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/STATUS?rev=570074r1=570073r2=570074view=diff == --- httpd/httpd/branches/2.0.x/STATUS (original) +++ httpd/httpd/branches/2.0.x/STATUS Mon Aug 27 04:28:22 2007 @@ -165,6 +165,10 @@ adjusted for 2.0 including both patches; http://people.apache.org/~wrowe/r568779-backport-2.0-r2.patch +1: wrowe +rpluem says: What is the reason for the patch to Makefile.in in your +proposal? Besides I think +sed 's#i^LIBTOOL = \(.*\)#LIBTOOL = $(SHELL) $(installbuilddir)/libtool $(LTFLAGS)#' +is wrong (Note the i before ^). and prior to r569934; +1: rpluem Yes, I'm a vim user who always forgets modern linux is happy to navigate and stay in insert mode ;-) That file will not be applied, please ignore (it's the proposed fix to solve vpath with external apr junk.) @@ -175,6 +179,9 @@ Backported to 2.0 (on top of log core patch, above); http://people.apache.org/~wrowe/r569535-backport-2.0.patch +1: wrowe + -1: rpluem: It does not apply to 2.0. Even if + http://people.apache.org/~wrowe/r568326-backport-2.0-r2.patch + is applied first. Reviewing, and will update, thank you.
Re: svn commit: r570074 - /httpd/httpd/branches/2.0.x/STATUS
Ruediger Pluem wrote: On 08/27/2007 09:17 PM, William A. Rowe, Jr. wrote: Yes, I'm a vim user who always forgets modern linux is happy to navigate and stay in insert mode ;-) That file will not be applied, please ignore (it's I thought just that ;-). Happened to me hundred times before. Especially if you work alternately with vi on Solaris and vi (aka vim) on Linux. Worse, vi on hpux where you have to cancel insert mode to avoid lots of extra spurious commands on arrow keys.
Re: svn commit: r569947 - /httpd/httpd/branches/2.2.x/STATUS
Plüm wrote: I wouldn't say that it is a no-op on Unix. Some logger programs might expect an open stderr, even if this points to /dev/null. So I am not in favour of this patch. Besides I understood that we no longer support Win9x. So why making an exception here? IMHO if things do not work correctly on Win9x, bad luck. I don't disagree. I raised it to point out why I deliberately neglected it. I went over your other observations, thank you for pointing out the issues with the patch. New one incoming. Bill
Re: prefork and APR_HAS_THREADS
Arvind Srinivasan wrote: Some popular Unix distros package two httpd binaries - one built with the prefork MPM and the other built with the worker MPM - but only one set of libraries and modules. I assume the libraries and modules are the ones compiled for the worker mpm. Is the performance impact of the APR_HAS_THREADS code blocks in these libraries/modules small/neglible as opposed to if they had been built for the prefork MPM? Negligible with a few exceptions. PHP is one of them, it becomes quite bulky when you --enable-zts. Yes, a module built for worker will work against prefork MPM, if the prefork MPM has been built against a threaded APR. Bill
[Fwd: svn commit: r570419 - in /httpd/httpd/branches/2.2.x: STATUS modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_util_ssl.h]
Since this changes the user experience, would you mind terribly
applying the CHANGES as well? (I format my STATUS entries for
CHANGES now, since a diff of CHANGES never applies clean ;-)
---BeginMessage---
Author: jim
Date: Tue Aug 28 06:40:01 2007
New Revision: 570419
URL: http://svn.apache.org/viewvc?rev=570419view=rev
Log:
Backported
Modified:
httpd/httpd/branches/2.2.x/STATUS
httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c
httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c
httpd/httpd/branches/2.2.x/modules/ssl/ssl_util_ssl.h
Modified: httpd/httpd/branches/2.2.x/STATUS
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=570419r1=570418r2=570419view=diff
==
--- httpd/httpd/branches/2.2.x/STATUS (original)
+++ httpd/httpd/branches/2.2.x/STATUS Tue Aug 28 06:40:01 2007
@@ -79,16 +79,6 @@
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
-* mod_ssl: Version reporting update; displays 'compiled against'
- Apache and build-time SSL Library versions at loglevel [info],
- while reporting the run-time SSL Library version in the server
- info tags. Helps to identify a mod_ssl built against one flavor
- of OpenSSL but running against another (also adds SSL-C version
- number reporting.) [William Rowe]
-http://svn.apache.org/viewvc?view=revrevision=520701
- Backported to 2.2;
-http://people.apache.org/~wrowe/r520701-backport-2.2.patch
- +1: wrowe, rpluem, jim
PATCHES PROPOSED TO BACKPORT FROM TRUNK:
Modified: httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c?rev=570419r1=570418r2=570419view=diff
==
--- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c (original)
+++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_init.c Tue Aug 28
06:40:01 2007
@@ -34,42 +34,21 @@
** _
*/
-static char *ssl_add_version_component(apr_pool_t *p,
- server_rec *s,
- char *name)
-{
-char *val = ssl_var_lookup(p, s, NULL, NULL, name);
-
-if (val *val) {
-ap_add_version_component(p, val);
-}
-
-return val;
-}
-
-static char *version_components[] = {
-SSL_VERSION_PRODUCT,
-SSL_VERSION_INTERFACE,
-SSL_VERSION_LIBRARY,
-NULL
-};
static void ssl_add_version_components(apr_pool_t *p,
server_rec *s)
{
-char *vals[sizeof(version_components)/sizeof(char *)];
-int i;
+char *modver = ssl_var_lookup(p, s, NULL, NULL, SSL_VERSION_INTERFACE);
+char *libver = ssl_var_lookup(p, s, NULL, NULL, SSL_VERSION_LIBRARY);
+char *incver = ssl_var_lookup(p, s, NULL, NULL,
+ SSL_VERSION_LIBRARY_INTERFACE);
-for (i=0; version_components[i]; i++) {
-vals[i] = ssl_add_version_component(p, s,
-version_components[i]);
-}
+ap_add_version_component(p, modver);
+ap_add_version_component(p, libver);
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s,
- Server: %s, Interface: %s, Library: %s,
- AP_SERVER_BASEVERSION,
- vals[1], /* SSL_VERSION_INTERFACE */
- vals[2]); /* SSL_VERSION_LIBRARY */
+ %s compiled against Server: %s, Library: %s,
+ modver, AP_SERVER_BASEVERSION, incver);
}
Modified: httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c?rev=570419r1=570418r2=570419view=diff
==
--- httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c (original)
+++ httpd/httpd/branches/2.2.x/modules/ssl/ssl_engine_vars.c Tue Aug 28
06:40:01 2007
@@ -635,31 +635,41 @@
static char *ssl_var_lookup_ssl_version(apr_pool_t *p, char *var)
{
+static char interface[] = mod_ssl/ MOD_SSL_VERSION;
+static char library_interface[] = SSL_LIBRARY_TEXT;
+static char *library = NULL;
char *result;
-char *cp, *cp2;
-
-result = NULL;
-
-if (strEQ(var, PRODUCT)) {
-#if defined(SSL_PRODUCT_NAME) defined(SSL_PRODUCT_VERSION)
-result = apr_psprintf(p, %s/%s, SSL_PRODUCT_NAME,
SSL_PRODUCT_VERSION);
-#else
-result = NULL;
-#endif
-}
-else if (strEQ(var, INTERFACE)) {
-result = apr_psprintf(p, mod_ssl/%s, MOD_SSL_VERSION);
-}
-else if (strEQ(var, LIBRARY)) {
-result = apr_pstrdup(p, SSLeay_version(SSLEAY_VERSION));
-if ((cp = strchr(result, ' ')) != NULL) {
+
+if
Re: svn commit: r570440 - /httpd/httpd/branches/2.2.x/CHANGES
[EMAIL PROTECTED] wrote: Author: jim Date: Tue Aug 28 07:18:05 2007 New Revision: 570440 URL: http://svn.apache.org/viewvc?rev=570440view=rev Log: document userland change ty kindly!
httpd-2.0.61
You'll note there is a -very- short list of remaining patches to consider for the 2.0 branch, and the logging stderr pool in particular would be good to backport. Because there is no shell, we forcefully kill the stderr pipe logger on pool cleanup before we start launching the new logs. In 2.2/trunk this wasn't a noticeable, we forcefully kill the shell, but the log program it launches keeps running in some cases. Bill
Re: Blackdot.be (ApacheMon ApacheMobile) - Questions sparked by the ApacheLounge fuss
Jorge Schrauwen wrote: I'd like to add an additional note to this but I'm unsure in how to phrase it. What I want to say is: That I take the source tarball's that are posted e.g. httpd-2.2.4-win32-src.zip (only official release no TR, svn etc). I'd also like to knew if I need to add an additional disclaimer that I don't offer any warranties if somehow (unlikely) manage to cost a company huge sums of money and they want to sue me. If you simply note these are the officially released sources and you provide compiled binaries under the Apache License 2.0 (with no warranty as spelled out under that license), you should be in reasonably good shape. If you export from a country that has cryptographic export controls (e.g. computer programs-as-munitions) you should either avoid shipping any SSL components or be very careful to follow the export regulations. Bill
Re: Blackdot.be (ApacheMon ApacheMobile) - Questions sparked by the ApacheLounge fuss
William A. Rowe, Jr. wrote: Jorge Schrauwen wrote: I'd like to add an additional note to this but I'm unsure in how to phrase it. What I want to say is: That I take the source tarball's that are posted e.g. httpd-2.2.4-win32-src.zip (only official release no TR, svn etc). I'd also like to knew if I need to add an additional disclaimer that I don't offer any warranties if somehow (unlikely) manage to cost a company huge sums of money and they want to sue me. If you simply note these are the officially released sources and you provide compiled binaries under the Apache License 2.0 (with no warranty as spelled out under that license), you should be in reasonably good shape. If you export from a country that has cryptographic export controls (e.g. computer programs-as-munitions) you should either avoid shipping any SSL components or be very careful to follow the export regulations. And as Jim says, don't take this as legal advise, you are best to consult with a lawyer, or a software redistributor in your country who's thoroughly reviewed the issue of redistributing or building binaries of open source software. Note there can be legal differences between a program source code and a functioning, compiled program, depending on your jursidiction ;-) Bill
Re: [PATCH] Eliminate 13 in modules/aaa/mod_authn_dbd.c / modules/aaa/mod_authnz_ldap.c
Graham Leggett wrote: Martin Kraemer wrote: Here's a patch to eliminate the 13, and to improve portability to EBCDIC machines by using apr_toupper(). Some of this fooness here revolves around charset issues, something I am not clear on for many platforms. The first question is, what is the charset of the names of environment variables on various platforms, the next is the charset of the names of LDAP attributes and database columns. It doesn't matter; we should only perform c-locale case folding. As soon as you get beyond that, the same unicode characters fold differently in different languages. Bill
Re: svn commit: r571879 - /httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c
Nick Kew wrote:
ObPedant:
14:42:30 2007 @@ -113,8 +113,8 @@
/* we break the URL into host, port, uri */
if (APR_SUCCESS != apr_uri_parse_hostinfo(p, url, uri)) {
-return ap_proxyerror(r, HTTP_BAD_REQUEST,
- apr_pstrcat(p, URI cannot be parsed: , url,
NULL));
+return ap_proxyerror(r, HTTP_BAD_REQUEST, apr_pstrcat(p,
+ URI cannot be parsed: , url, NULL));
The second arg to ap_pstrcat is presented as a new arg to ap_proxyerror.
The old formatting was better.
+1 to niq's observation
- this is now quite illegible in terms of how it is doing what it does.
Re: svn commit: r572298 - /httpd/site/trunk/dist/tools/release.sh
Do we want to pick up the new apr-util's which now include Roy's commits to pick up db 4.6 and other fun test/ fixes? (including running a bunch of tests which were previously 'interactively' somewhat useless). Just asking, I'll roll both apr's and apu's, or just apr's. Whichever is fine by me (at least apu didn't have the regression headaches.) apr_xxx_in_srclib=1 -apr_tag=1.2.10 +apr_tag=1.2.11 apu_tag=1.2.9 apr_xxx_in_srclib=1 -apr_tag=1.2.9 -apu_tag=1.2.8 +apr_tag=1.2.11 +apu_tag=1.2.9
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 Apache HTTP Server release candidate tarballs, located, as expected at: http://httpd.apache.org/dev/dist/ [ ]apache_1.3.39 -0.1 The tarball apache_1.3.39.tar.gz explodes into apache-1.3/, which isn't exactly conventional. I'll be happy to continue and check this functionally on win32, but would be much more enthusiastic if it unpacked to apache_1.3.39/. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jim Jagielski wrote: Hmmm... yeah, bummer. If that's it though, I'm +1 on keeping as is... we can document this. Or, we could *gasp* just reroll :/ Or we can repack the same files. This is a packaging artifact, not an artifact of source control. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
+1:1.3.39 Builds with nothing except for signedness warnings on Win32 (mostly related to goofy FD_SET declarations by MS). So no adverse symptoms. Jim Jagielski wrote: On Sep 4, 2007, at 8:15 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Hmmm... yeah, bummer. If that's it though, I'm +1 on keeping as is... we can document this. Or, we could *gasp* just reroll :/ Or we can repack the same files. This is a packaging artifact, not an artifact of source control. repackaged and uploaded. Should sync in a coupla hours. Sigs look great, package contents (adjusted to new path) check out. I should really spend some cycles and update release.sh for 1.3 :) Considering how often that might be used again (perhaps never?) - knock yourself out. That's the real spirit of scratching our own itches :) Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: little things: mod_bucketeer.so is not build out of the box with Win32 gui-build. Not necessary (except for testers). Trivial for the developer to create (along with many similar testing modules - instead of building the BuildBin target, use BuildAll target. zlib1.dll is now copied to /bin , seems to me not necessary. zlib1.dll doesn't come from Microsoft, it's quite necessary. (I can't imagine you don't ship it?!?) It's used by mod_deflate, and also by openssl 0.9.8 - we anticipate most 2.2 users to use that version as it was current when Apache 2.2.0 was first released. In 2.0 we anticipated 0.9.7 which doesn't enable zlib by default, and we had compiled the required zlib 1.1.x sources into mod_deflate.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: I get this kind off error too when stopping. Never seen before: Failed to dup STDIN: Bad file descriptor. Error in my_thread_global_end(): 251 threads didn't exit I expect you are talking about mod_fcgid again?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: I don't have any cgi scripts so I tried to get the printenv test-cgi file to work. I get 500 and error_log has this. [Wed Sep 05 20:44:36 2007] [error] [client 87.66.74.14 http://87.66.74.14] Premature end of script headers: printenv.pl [Wed Sep 05 20:50:24 2007] [error] [client 87.66.74.14 http://87.66.74.14] Premature end of script headers: test.cgi Researching! Would you share which version of Windows?
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: I have no zlib1.dll on my box and mod_deflate works fine. It's included/static in mod-deflate.so. Next time I shall ship it too, does not harm. FYI - I haven't dug into the theory, but I'd presumed a possible race and certainly suboptimal behavior if you go with OpenSSL's 'zlib-dynamic' win32 implementation (actually any zlib-dynamic for a server application, no matter which platform). The optimal behavior is to enable-zlib to openssl so it's simply present upon first-use of compressed TLS streams. This is how I've configured openssl-0.9.8. If you were to link static to both openssl and mod_deflate on win32, of course that also works (and is also a redundancy ;-) Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
William A. Rowe, Jr. wrote: Jorge Schrauwen wrote: I don't have any cgi scripts so I tried to get the printenv test-cgi file to work. I get 500 and error_log has this. [Wed Sep 05 20:44:36 2007] [error] [client 87.66.74.14 http://87.66.74.14] Premature end of script headers: printenv.pl [Wed Sep 05 20:50:24 2007] [error] [client 87.66.74.14 http://87.66.74.14] Premature end of script headers: test.cgi Researching! Would you share which version of Windows? Well, not windows apparently, on win32 we only install printenv.pl (presuming no /bin/sh on that platform to 'test.cgi'). Without perl, of course printenv.pl won't run either (and you may need to tweak the shebang line appropriately after install). If you have a faux-unix shell, you can try out test.cgi after you tweak its shebang line. AND /cgi-bin/printenv.pl is working, no hassle for me, here with 2.2.6. (Were you testing that, or 2.0.61, or 1.3.39?) On unix, we don't set these as executable out of the box. Toggle the perms to 755 and tell us what happens. All such scripts are inherently xss-able with bullshit utf-7 auto-detection by our least favorite, most anamorphic user agent, so it actually isn't a good idea to enable them by default for a production server. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: With 2.2.6 third party mod mod_fcgid (Fast cgi) is broken. With 2.2.5 RC it was all fine. mod_fcgid is widely used in the community with php. I guess my puzzlement is that the fastcgi model I understand; fork... instantiate child spining cgid listener - on accept... fork run with only a single instantiated child ready to be forked off in multiple copies simply doesn't work on win32. You can emulate the behavior, but you either end up exec'ing each time, or you end up recycling the same process leading to a less secure process separation model. In any case, the changes to Win32 now mirror the OS2 model, so one expects if mod_fcgid is broken on Win32, its been broken on OS2. So it's likely you'll need to ask the maintainers of the win32 port of mod_fcgid what is going on, and advise them that process inheritance has been changed to inhibit the leaking of pipes on the win32 platform, a problem that the PHP community brought to us long ago with respect to the unix platform (and was resolved with close_for_exec logic in the httpd pool model, a concept that doesn't translate to win32.) Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: What exectly is not working in mod_perl? my limited mod_perl config is working fine. On 9/5/07, *Steffen* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Also mod_perl is not working here with Win32. No indication in the logs. FWIW; I believe I know why mod_perl is not as verbose on Win32 (oh DUH moment)... this is not a regression, but when we clip in the Event logger pipe we actually plug the FD into the faux-posix/stdio FILE emulation API for Win32. With the error log, we never have (in the past). I can certainly work up a fix so that stdin/out/err and faux-fd 0, 1, 2 behave as expected from APR when not using apr file io. But this will also more tightly bind to a specific MSVC version, and those binaries built across multiple MSVC versions (e.g. AS perl built on VC 6, AS python built on VC 7.1, Apache+mods built with VS8) will be even more likely to implode :) Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jim Jagielski wrote: Available for your testing pleasure, 3, count 'em, 3 [+1]apache_1.3.39 [+1]httpd-2.0.61 [+1]httpd-2.2.6 Thanks!! No, thank YOU :) Small chaos today as some reports contradicted my earlier testing, but I see no regressions, with the exception possibly of mod_fcgid which is playing with some internals of apr. Apparently mod_perl/mod_cgi do work as expected (better, in the case of mod_cgi). Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: I the meantime we have to advise the users not to use 2.2.6 because is not compatible with some mods (not just mod_fcgid). We shall advise to stay on 2.2.4 or 2.2.5 RC. If you would like to clear up FUD (some mods) with explicit mods that would be productive. It would also be productive to discuss your concern with the mod_fcgid maintainers, as the apr behavior is not likely to be regressed to the previous behavior of leaking file handles (which I suspect mod_fcgid had leveraged). If I understand your later post; mod_fcgid is not working for me, either with Perl or with my own FCGI test program. your issues with mod_perl were in conjunction -with- mod_fcgid? Just trying to narrow down the focus. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: Windows users (my self included) usually go like: Dudez XYZ is broken, Fix it, Fix it, Fix it. When the dev's look at it and ask for more information they usually don't get it. So it isn't fixed at all or as fast as a linux bug would be. You know, you hit the nail on the head. http://httpd.apache.org/dev/debugging.html has some great information, presuming the distributor of your win32 binaries actually provides the .pdb debugging context files that are required to emit a legible backtrace. (Ok, not strictly required, a significantly less helpful backtrace is emitted without .pdb's, no arguments from the call stack for example, but only if the recommended /Oy- flag is passed to the compiler. OpenSSL doesn't enable this flag by default, so a crash behind an openssl callback from a stock build of openssl will produce an entirely illegible backtrace.) I'm going to rip section 2 of that document in two, one for live backtraces, and a second for JIT/postmortem backtraces, since these seem shrouded in mystery from many users/developers (and they shouldn't be). Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: I tried to compiled mod_fcgid myself to see if I can replicate the problem. I can't even compiled it against 2.2.6. I get a lot of link errors agains APR. Silly question, did you add libapr-1.lib, libaprutil-1.lib libhttpd.lib to the link command? (Worse, if you did add apr-1.lib aprutil-1.lib, those are static libraries and wouldn't even interface into the running instance of the libraries in a running httpd process). Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: Oh, btw: mod_perl (also build with VC8) is not working with 2.2.6, with 2.2.5 RC no single issue. Perl, mod_perl, httpd and apr all built with VC8? Or is this AS perl or some other? Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Steffen wrote: The later post was a report of an other tester, sorry no answer I have. Yes, I dicusssed it with the maintainer of mod_fcgid today. He is puzzling now an as I told before, we have to wait. Before he puzzles too long, you might want to ensure you have a full rebuild of mod_fcgid against apr-1.2.11, that is the one bundled in the new httpd-2.2.6. If it *did* use include/arch/win32/*.h files (which does *not* following the versioning rules, because those entries are strictly private to the library) --- there's a good chance that a new module build is required. It occurred to me that since the authors do probably delve into the win32 internals, you might want to check this out.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: Hmmz still getting link errors :( --- S:\source\x86\modules\mod_fcgid.2.1apxs -llibhttpd -llibapr-1 -llibaprutil-1 -c -i -a mod_fcgid.c cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG-IS:\httpd- 2.2\include /c /Fomod_fcgid. lo mod_fcgid.c mod_fcgid.c link kernel32.lib /nologo /subsystem:windows /dll /machine:I386 /libpath:S:\httpd-2.2\lib /out:mod_fcgid.so libhttpd.lib libapr-1.lib libaprutil-1.libmod_fcgid.lo Creating library mod_fcgid.lib and object mod_fcgid.exp mod_fcgid.lo : error LNK2001: unresolved external symbol _merge_fcgid_server_config That's bizare - most any author would set these up as static's within their modules since there is no reason to export them (or attempt to bind to an exported symbol. Either way, I suspect mod_fcgid.c has more source files than the single module source, based on these emits. (Usually it would scream about exported symbol being imported). While on the subject, if this depends on a libfcgid, you probably need to bind to that lib, too.
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: Didn't even notice... I usually take the tar.gz source and add in apr-iconv myself then run lineends.pl that is included in srclib/apr/build/, I also run cvtdsp.pl -2005 on there before I start. I didn't even seen a - win32-src.zip at that time. Bingo - that's how I do it. In fact the httpd-* win32-src files start out their existence as unix httpd*.tar.gz unix targets. In this case, I had moved apr-iconv to srclib/ in my builds, but not in the package, and that's what exploded 2.2.6. When I xcopy /s/v *.mak etc, it just added iconv build foo with no source foo. Fortunately, I (and Issac) caught this even before Jim took things live, so no bother. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Issac Goldstand wrote: Uh. Maybe I've lost it, but where's the source for apr-iconv in http://httpd.apache.org/dev/dist/httpd-2.2.6-win32-src.zip? All I get is an .rc file and a couple of .deps and .maks I just pulled an OH SHIT moment myself building on x86_64 windows... ... there are -r2.zip packages up now, and I just updated the site svn, but I presume Jim hadn't pulled that site update to live so I'm leaving it for him. C.f. http://www.apache.org/dist/httpd/httpd-2.2.6-win32-src-r2.zip ...not quite arrived from our staging to live server yet. Bill
Re: svn commit: r573505 - in /httpd/site/trunk: docs/index.html xdocs/index.xml
[EMAIL PROTECTED] wrote: Log: Let's not reference a survey that is more than a year out of date ROFL - we are at 73% if you trust http://www.securityspace.com/s_survey/data/200708/index.html while only ~51% if you trust http://news.netcraft.com/archives/2007/09/03/september_2007_web_server_survey.html Depends on how many blogs you subscribe as 'unique machines' I'm guessing. Bill --- httpd/site/trunk/docs/index.html (original) +++ httpd/site/trunk/docs/index.html Fri Sep 7 01:40:35 2007 @@ -70,9 +70,7 @@ efficient and extensible server that provides HTTP services in sync with the current HTTP standards./p pApache has been the most popular web server on the Internet since -April 1996. The November 2005 a href=http://news.netcraft.com/archives/web_server_survey.html;Netcraft Web Server Survey/a -found that more than 70% of the web sites on the Internet are using Apache, -thus making it more widely used than all other web servers combined./p +April 1996. /p pThe Apache HTTP Server is a project of the a href=http://www.apache.org/;Apache Software Foundation/a./p /blockquote /td/tr Modified: httpd/site/trunk/xdocs/index.xml URL: http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/index.xml?rev=573505r1=573504r2=573505view=diff == --- httpd/site/trunk/xdocs/index.xml (original) +++ httpd/site/trunk/xdocs/index.xml Fri Sep 7 01:40:35 2007 @@ -15,10 +15,7 @@ with the current HTTP standards./p pApache has been the most popular web server on the Internet since -April 1996. The November 2005 a -href=http://news.netcraft.com/archives/web_server_survey.html;Netcraft Web Server Survey/a -found that more than 70% of the web sites on the Internet are using Apache, -thus making it more widely used than all other web servers combined./p +April 1996. /p
Re: svn commit: r573264 - /httpd/httpd/trunk/include/scoreboard.h
jean-frederic clere wrote: That is going to break: In mod_proxy.h: int ap_proxy_lb_workers(void); In server/scoreboard.c: +++ static APR_OPTIONAL_FN_TYPE(ap_proxy_lb_workers) *proxy_lb_workers; +++ which is fine - this is trunk. Heaven forbid we backport it ;_)
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: Ok basic example as stated here: http://fastcgi.coremail.cn/configuration.htm#regular%20fastcgi makes the server spit out these again: [Fri Sep 07 17:49:51 2007] [error] [client 192.168.1.4 http://192.168.1.4] Premature end of script headers: printenv.pl Unfortunately the drwatson log didn't tell me a whole lot. If you crank the loglevel to 'debug' can we get any further hints about the failure? Does fcgid do any logging itself?
[Fwd: DO NOT REPLY [Bug 43329] New: - apr_proc_create behavior change]
FYI - this bug appears to be the root of several modules no longer behaving as expected on Win32 platforms. It takes me back to a question I raised on apr quite a while ago, what does *unix* do with an unset child_in/child_out/child_err procattr member? If it is unset, does the child inherit the processes' std handle? AIUI - with our apr implementation, it does. Bill ---BeginMessage--- DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43329. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=43329 Summary: apr_proc_create behavior change Product: APR Version: HEAD Platform: Other OS/Version: Windows 2000 Status: NEW Keywords: PatchAvailable Severity: normal Priority: P2 Component: APR AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] apr_proc_create now passes zero instead of INVALID_HANDLE_VALUE for STDIN, STDOUT, and STDERR which are zero in the procattr. This change was caused by Revision 568819. Several 2rd-party modules (mod_fcgid, mod_fascgi, mod_perl, etc.) test explicitly for INVALID_HANDLE_VALUE and are broken by this behavior change. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message---
Re: svn commit: r573688 - /apr/apr/trunk/build/fixwin32mak.pl
Windows httpd on Studio 2005 users, you might be interested in this
small hack to fixwin32mak.pl - after applying it I'm able to build
against x86 or x64 cl+link with no trouble at all (other than some
noisy emits that still need to be cleaned up.
Bill
Log:
Strip out the /machine from link.exe, in this day and age each CPU
gets it's own link.exe in it's own path, e.g. you need to set up the
path for amd64 and you will get that cl compiler, and that linker.
Although I had already stripped /machine from the .pdb's, the silly
export put one back. Axe it for good when touching up our .mak files.
--- apr/apr/trunk/build/fixwin32mak.pl (original)
+++ apr/apr/trunk/build/fixwin32mak.pl Fri Sep 7 13:12:49 2007
@@ -86,6 +86,15 @@
$verchg = -1;
undef $orig;
}
+# With modern LINK.EXE linkers, there is a different LINK for
+# each platform, and it's determined by the file path. Best
+# that here, after we compiled the code to the default CPU,
+# that we also link here to the default CPU. Omitting the
+# /machine spec from the .dsp was not enough, MSVC put it back.
+#
+if ($src =~ s#^(LINK32_FLAGS=.*) /machine:(x|IX|I3)86 #$1 #) {
+$verchg = -1;
+}
print $dstfl $src;
}
undef $srcfl;
Re: Apache proxy engineering specs
Shaw, Dan wrote: 1. Does a apache proxy server create stateful or stateless connection upon request? It might help to clarify right off that RFC 2616 defines HTTP/1.1 and prior as stateless protocols. So the answer is no, any aggregation is an illusion. For stateful proxied connections it is necessary to use proxy CONNECT method from the client to the back end. Bill
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: Yeah I figured it out a bit later and it indeed seems broke. Not sure whats wrong though I posted a debug log + user dump yesterday. The debug log was unfortunately not very interesting, since it wasn't doing anything out of the ordinary at the time you interrupted the process. It's also not quite decipherable, you would have to build at minimum with /Oy- and ideally with /Zi for your compile flags, /debug (to create pdb's also for third party modules) to the linker. And to let Dr Watson dig through all the particularities of your system libraries, you can use WinDbg (a free download from MS) which has a very nice feature; you set up a local SymStore that can suck down the .pdb's of almost any Microsoft shipped .dll through an envvar that looks like; _NT_SYMBOL_PATH=srv*G:\symstore*http://msdl.microsoft.com/download/symbols ...like magic your crash dumps will include all backtraces through the win32 dll's and nt kernel. We do know something more about this flaw at this point; you'll find most of the details at http://issues.apache.org/bugzilla/show_bug.cgi?id=43329 Thankfully Tom's created this incident after (correctly) diagnosing what libfcgid does on Win32. It's trivial to solve, as Tom noted and I had further corrected in that incident, however it reverts to existing broken behavior with respect to APR. Apparently mod_fcgid has long assumed that invalid handles are it's clue that it should run. Foolish Win32-ish assumption; and the way it behaves when compiled under VC6 and VC8 seem to significantly disagree. This might be because VC8 tries to be more clever about repairing broken stdhandles for console applications. The bottom lines are these; the APR library exists to keep applications consistent - the basic behavior is that fd's 0, 1, 2 (Win32's STD HANDLE values) inherit the parent's pipes if not explicitly defined; some apps fail miserably when runing in a service context with a sub-par set of handles (e.g. cmd.exe for one, while on unix a program will open a file only to discover that fd occupies slot 0, 1, or 2 and becomes corrupted). So the question becomes; fix libfcgid? And/or; add an explicit and very platform independent feature to NOT inherit undefined handles from the parent to child process? If this feature were added, it would be possible to say NO_PIPE to all three handles, and on unix have fd's 0/1/2 all unused, on windows have them all contain INVALID_HANDLE_VALUE's. I'm sure there is a valid use case for this across platforms. Bill
Re: Corrupted archive file?
I'm sure you ment to send this to the tomcat devs. Dan Schwartz wrote: The file http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.17/bin/apache-tomcat-5.5.17.exe appears to be corrupted. In fact it seems to be about half the size it should be, as compared with other distributions of Tomcat. Could you please check this and let me know? I need this version because it is the only one that works with ESRI's ArcIMS 9.2 (according to their documentation). Thanks, --Dan Schwartz
Re: SSL_VERSION_LIBRARY
Zvi Har'El wrote: This looks similar to PR 43334 (https://issues.apache.org/bugzilla/show_bug.cgi?id=43334). Could you please test my diagnostic patch from there? Yup - that patch would solve it since we don't reinit static char*library to null on every unload/reload cycle. The fix is either to do it always (as this patch does) - or since it might outlive p, delve down to parent pool (process scope) and allocate from there. Bill
Re: Patch (against trunk) for bug #41960
Jose Kahan wrote: I had also submitted a new test procedure for the test suite. It hasn't yet been commited, although it reproduces the faulty behavior that my patch is intended to fix. Fantasic :) I don't know what else to do to be able to submit a valid bug report and potential patch to you: patch against trunk, new test for the perl framework, ... chocolate-chip cookies? Cookies are good :) Seriously, I'll look, the patch is very easy to follow, the possible side effects aren't so trivial. (I post this as one recently bitten by such side-effects, heh.) I may be missing something in the Apache procedure for submitting this. I would have expected someone to point it out to me since I first submitted the bug report late March. Yes - we have a limited number of voulenteer committers. The best thing to do is to ping the list once every month or so if you want to champion your patch. Eventually, someone's cycles will free up. There's a reason for that exclusion originally and that has to be reviewed before we jump on it, but in principal I'd agree to consider that patch. Bill
Re: Want to kill Apache process when its parent process gets killed.
Ashwani Kumar Sharma wrote: The httpd.exe of Apache web server has two processes running in windows. When we kill the parent httpd.exe the child httpd.exe is still running and listening to the web request. I don't want this. Since you forcibly terminate the server process(es) your instance of httpd.exe won't be cleaned up. It's really not terribly graceful. It's the unix equivilant of sending kill -KILL instead of kill. Ick. I believe you can solve your entire problem by telling httpd.exe to shut down, and avoiding the abandoned children. The API would be GenerateConsoleCtrlEvent to force a CTRL_C_EVENT at the process http://msdn2.microsoft.com/en-us/library/ms683155.aspx all of which is to say you aren't using httpd.exe as a service, which is where most of the testing and evalution effort is invested in. Since you are replacing the parent wrapper you might consider dropping the parent altogether (see the -X flag, I'm not sure if -DONE_PROCESS is the same effect on win32 offhand). Bill
Re: AW: SSL_VERSION_LIBRARY
Jim Jagielski wrote: What with this and the Win32/apr issues, seems to me that we should consider a 2.2.7 out soonish :) I was about to suggest the same :) With Win32/APR there isn't a fix. Not yet at least, Tom Donovan and I are going back and forth with ideas that break the fewest binaries (it's not going to be workable to require users to obtain new copies). So some fix that is entirely made by a minor change to mod_fcgid itself, and not the individually compiled fcgid's, is more appropriate. But I've sort of put that aside to look at the mod_perl issues that some user had reported. Will have some update shortly this week. The SSL_VERISON_LIBRARY is thankfully quite fixable, something in, say patches/apply_to_2.2.6 would certainly go a long ways to helping in the very short term. Bill
Re: windows cl/link invocations
Eric Covener wrote: For debugging a windows build, is there a simple change to the Apache build/workspace that will print all the cl.exe/link.exe invocations? FWIW I'm using VC6 and my build is kicked off as below: msdev apache.dsw /MAKE BuildBin Win32 Release I see that sometimes while poking around in individual DSP files, these odd .plg files are generated but not when I do the full build .plg are associated with a workspace not a project. For what it's worth, you might be interested in running nmake -f Makefile.win _apacher full.log 21 to see the complete compilation.
IE7, application/x-tar and our archive.apache.org .tar.gz's
There seems to be troubles in paradise. cc'ing httpd who had recently updated mime-types. I'm not speaking about IE7's refusal to assign quality quotients to their Accept: alternatives, no, this is a bit trickier and it looks like we are in the wrong. An example document, /dist/httpd/httpd-2.2.6.tar.gz is requested and received complete via netcat sniffing of request and query to a.a.o. Firefox etc all receive the document complete. But within IE7, the request is truncated at 4864kb instead of the expected 6mb. My best guess is that IE believes it can grok the file as it's advertised content type. This is observed on a number of different IE7 boxes across several ISPs speaking to archive.a.o. Best I can figure, this is really application/x-tar+x-gzip (or would that be application/x-gzip+x-tar?) if we don't want to (and we don't want to) advertise the content stream as gzip'ed (preventing automatic inflation which would cause md5/asc sigs to mismatch). Thoughts? Bill GET /dist/httpd/httpd-2.2.6.tar.gz HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */* Accept-Language: en-us UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) Host: archive.apache.org Connection: Keep-Alive HTTP/1.1 200 OK Date: Tue, 11 Sep 2007 21:59:17 GMT Server: Apache/2.3.0-dev (Unix) Last-Modified: Thu, 06 Sep 2007 19:31:02 GMT ETag: b1b7be-5bfe97-9007c980 Accept-Ranges: bytes Content-Length: 6028951 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/x-tar
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
Nick Kew wrote: On 11 Sep 2007, at 23:26, William A. Rowe, Jr. wrote: Best I can figure, this is really application/x-tar+x-gzip (or would that be application/x-gzip+x-tar?) if we don't want to (and we don't want to) advertise the content stream as gzip'ed (preventing automatic inflation which would cause md5/asc sigs to mismatch). I disagree. The right thing is indeed to advertise it as gzipped, and provide sigs for the uncompressed tarballs (alongside the compressed ones). In fact we could reduce the number of sig files by providing MD5s for everything in one file, and then just PGP-sign the MD5 file. On the other hand, this is really application/x-gzip ment for another application to inflate, and then untar. Seriously, if I download 20 packages getting ready to do things on a third machine, I sure as hell don't want to scp those packages across my intranet in an inflated tar format! And definitely not from an unpacked tar! HTTP/1.1 200 OK Date: Tue, 11 Sep 2007 21:59:17 GMT Server: Apache/2.3.0-dev (Unix) Last-Modified: Thu, 06 Sep 2007 19:31:02 GMT ETag: b1b7be-5bfe97-9007c980 Accept-Ranges: bytes Content-Length: 6028951 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/x-tar An application that understands tar may unpack that. No, because you missed Content-Encoding: gzip and at that point any user agent can inflate and unpack it, of course. That is one alternative if ment to be viewed in a user agent. These particular archives are not ment to, however, at the time they are obtained. Consider mirrors, do we expect the mirror or proxy to make local decisions about storing this compressed or uncompressed? Certainly not. Does a Content-Disposition header help with IE7? No clue offhand, but that isn't a HTTP/1.1 field so I couldn't care less. I think this really is our fault for representing the wrong Content-Type. And would it help browsers if we supply a Content-MD5 header? Absolutely -1. I'd have no problem with a Content-MD5 footer, but we don't know the MD5 until the entire response is composed. As a matter of efficiency only a footer makes sense.
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
Nikolas Coukouma wrote: Due to the lack of a real standard (AFAIK ...) that doesn't use content encodings, it's hard to say what is correct. Agreed... If it's decided to avoid the use of Content-Encoding (is the hash and signature problem that bad?) Yes if mirrors can't be authenticated... I'd suggest the use of the existing application/x-tgz over a new type. That's a rational alternative to consider, thanks! And thanks for the pointer at the previous discussion. Bill
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
Nikolas Coukouma wrote: It should also be noted that this has been discussed here before, in February of 2003 http://mail-archives.apache.org/mod_mbox/httpd-dev/200302.mbox/[EMAIL PROTECTED] Actually this wasn't; that subject was filename munging and content-type inference. This is honest-to-goodness content-type handling.
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
Jochen Wiedmann wrote: On 9/12/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But within IE7, the request is truncated at 4864kb instead of the expected 6mb. My best guess is that IE believes it can grok the file as it's advertised content type. Is it possible that the browser invokes a content handler (for example winzip or something like that) on the transferred file, which detects at some point, that the mime type is wrong and therefore fails, causing the browser to abort the connection? This is pretty much a virgin 2003 R2 SP2 Server with Visual Studio 2005 installed, upgraded to IE7. It really isn't that decorated, a quick delve shows that HKCR/.tar does map to Content Type application/x-tar (as it should) and that's associated to PercievedType compressed. Simply the windows compressed folder handler. Yet and still, this was a save as file, not an attempt to open. FWIW MS maps .tgz to Content Type application/x-compressed, whatever the heck that's supposed to mean :) Bill
Re: AW: SSL_VERSION_LIBRARY
Looking at the scope of all these static calls, I really believe the
patch is this simple (process-pool survives the entire httpd);
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 574494)
+++ ssl_engine_vars.c (working copy)
@@ -190,7 +190,7 @@
*/
if (result == NULL) {
if (strlen(var) 12 strcEQn(var, SSL_VERSION_, 12))
-result = ssl_var_lookup_ssl_version(p, var+12);
+result = ssl_var_lookup_ssl_version(s-process-pool, var+12);
else if (strcEQ(var, SERVER_SOFTWARE))
result = ap_get_server_banner();
else if (strcEQ(var, API_VERSION)) {
@@ -262,7 +262,8 @@
ssl = sslconn-ssl;
if (strlen(var) 8 strcEQn(var, VERSION_, 8)) {
-result = ssl_var_lookup_ssl_version(p, var+8);
+result = ssl_var_lookup_ssl_version(c-base_server-process-pool,
+var+8);
}
else if (ssl != NULL strcEQ(var, PROTOCOL)) {
result = (char *)SSL_get_version(ssl);
Re: AW: SSL_VERSION_LIBRARY
William A. Rowe, Jr. wrote: Looking at the scope of all these static calls, I really believe the patch is this simple (process-pool survives the entire httpd); Sorry - scratch that. I wasn't counting the frequency of pstrdup calls. Just begging for optimization :)
Re: Add 2.2.6 to bugzilla
Sander Temme wrote: Ruediger Pluem wrote: Can someone with appropriate permissions please add version 2.2.6 to bugzilla such that bug reports can be done correctly? Thanks. I don't have my Bugzilla login password on me right now... I'll add this tomorrow when I get home, if no one beats me to it. Had beat you to it. Everything httpd-wise and apr-wise is in sync.
Re: AW: SSL_VERSION_LIBRARY
William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Looking at the scope of all these static calls, I really believe the
patch is this simple (process-pool survives the entire httpd);
Sorry - scratch that. I wasn't counting the frequency of pstrdup calls.
Just begging for optimization :)
Without fretting the optimizations, try this for the cleanest patch I could
think of (remember, these are static internal functions)
Index: modules/ssl/ssl_engine_vars.c
===
--- modules/ssl/ssl_engine_vars.c (revision 574494)
+++ modules/ssl/ssl_engine_vars.c (working copy)
@@ -49,7 +49,7 @@
static char *ssl_var_lookup_ssl_cert_verify(apr_pool_t *p, conn_rec *c);
static char *ssl_var_lookup_ssl_cipher(apr_pool_t *p, conn_rec *c, char *var);
static void ssl_var_lookup_ssl_cipher_bits(SSL *ssl, int *usekeysize, int *algkeysize);
-static char *ssl_var_lookup_ssl_version(apr_pool_t *p, char *var);
+static char *ssl_var_lookup_ssl_version(apr_pool_t *pp, apr_pool_t *p, char *var);
static char *ssl_var_lookup_ssl_compress_meth(SSL *ssl);
static int ssl_is_https(conn_rec *c)
@@ -190,7 +190,7 @@
*/
if (result == NULL) {
if (strlen(var) 12 strcEQn(var, SSL_VERSION_, 12))
-result = ssl_var_lookup_ssl_version(p, var+12);
+result = ssl_var_lookup_ssl_version(s-process-pool, p, var+12);
else if (strcEQ(var, SERVER_SOFTWARE))
result = ap_get_server_banner();
else if (strcEQ(var, API_VERSION)) {
@@ -262,7 +262,8 @@
ssl = sslconn-ssl;
if (strlen(var) 8 strcEQn(var, VERSION_, 8)) {
-result = ssl_var_lookup_ssl_version(p, var+8);
+result = ssl_var_lookup_ssl_version(c-base_server-process-pool,
+p, var+8);
}
else if (ssl != NULL strcEQ(var, PROTOCOL)) {
result = (char *)SSL_get_version(ssl);
@@ -633,7 +634,7 @@
return;
}
-static char *ssl_var_lookup_ssl_version(apr_pool_t *p, char *var)
+static char *ssl_var_lookup_ssl_version(apr_pool_t *pp, apr_pool_t *p, char *var)
{
static const char interface[] = mod_ssl/ MOD_SSL_VERSION;
static char library_interface[] = SSL_LIBRARY_TEXT;
@@ -642,7 +643,7 @@
if (!library) {
char *cp, *cp2;
-library = apr_pstrdup(p, SSL_LIBRARY_DYNTEXT);
+library = apr_pstrdup(pp, SSL_LIBRARY_DYNTEXT);
if ((cp = strchr(library, ' ')) != NULL) {
*cp = '/';
if ((cp2 = strchr(cp, ' ')) != NULL)
Re: AW: SSL_VERSION_LIBRARY
Plüm wrote: Also looks good for me. Thanks for working this out. Mind to attach this patch to PR43334 (https://issues.apache.org/bugzilla/show_bug.cgi?id=43334) so that people there can test? Better yet, committed the patch to trunk and pointed the url @ the commit.
Re: [Fwd: DO NOT REPLY [Bug 43329] New: - apr_proc_create behavior change]
Joe Orton wrote: On Fri, Sep 07, 2007 at 02:59:10PM -0500, William Rowe wrote: FYI - this bug appears to be the root of several modules no longer behaving as expected on Win32 platforms. It takes me back to a question I raised on apr quite a while ago, what does *unix* do with an unset child_in/child_out/child_err procattr member? If it is unset, does the child inherit the processes' std handle? AIUI - with our apr implementation, it does. That's what the Unix implementation does; fds 0-2 will be untouched so will remain exactly as in the parent. (Of course, none of this stuff is documented as an API constraint.) Right, very true. It's implicit, and a lurking surprise. So (of course) is the reliance on invalid handles, null handles and so on. We've been bitten by MS's own changes between NT and XP as it evolved to go from some handle to NULL handle in the service context. Since it -seems- we can establish a contract, and we didn't have one before, this is something worth fixing if we can do so -without breaking abi-. I'm going to suggest an APR_NO_FILE flag, similar to APR_NO_PIPE, but with the added purpose of 'closing' (not inheriting to the running child) that undesired FD on any platform. I believe the patch will allow mod_fcgid maintainers to modify their module to use a documented behavior instead of an 'undocumented feature'. For 95% of the world, it should be a noop of a change. Bill
Re: svn commit: r574884 - /httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
Joe Orton wrote: On Wed, Sep 12, 2007 at 10:47:03AM -, William Rowe wrote: Author: wrowe Date: Wed Sep 12 03:47:02 2007 New Revision: 574884 URL: http://svn.apache.org/viewvc?rev=574884view=rev Log: Resolve storage of process-lifespan version strings for OpenSSL, while using request-lifespan copies for manipulation. Ewww. This passes around a process-global pool to functions which can get invoked at any time during request processing, which just invites a thread-safety fubar down the line. It only happens to be safe now because the function is invoked at startup. s/functions/function/ Is there a reason you prefered this to the patch I posted? Simplicity? That's really the entire reason. In fact it is thread-safe, although if you wanted the per-request flavor to pass NULL and explode in an inconceivable manner, that would be OK too. We call this during each config iteration, logging (even if logs are off we call the silly function) the version in-use. Ergo it's never NULL once we've spun off threads and are off to the races. Correct? Bill
Re: svn commit: r574884 - /httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
William A. Rowe, Jr. wrote: Joe Orton wrote: Ewww. This passes around a process-global pool to functions which can get invoked at any time during request processing, which just invites a thread-safety fubar down the line. It only happens to be safe now because the function is invoked at startup. We call this during each config iteration, logging (even if logs are off we call the silly function) the version in-use. Ergo it's never NULL once we've spun off threads and are off to the races. Would you be happier with a comment at the initialization formatting call which says this call is required to initialize the ssl version string?
Re: AW: SSL_VERSION_LIBRARY
Joe Orton wrote: On Mon, Sep 10, 2007 at 09:47:24PM +0200, Ruediger Pluem wrote: On 09/10/2007 08:40 AM, Plüm wrote: That was the goal of my diagnostic patch: Finding out if we have a pool issue. Looks like we have. I guess the right fix is as you say to use the parent pool (process scope). Not 100% sure regarding the correct pool, but would that be the correct fix That's not really thread-safe, and it ought to be, though we might get away with it since it's called during startup. But rather than guessing pools, actually caching the stuff once at startup is probably cleanest, I've reviewed, I'd be entirely happy with the short-and-sweet hack on 2.0 and 2.2 if you would like this to become the new logic for trunk. Would that appeal? Bill
Re: Plans to release binaries?
Martin Kraemer wrote: Hi, A customer asked me whether WIN32 binaries for the new 2.0.61 and 2.2.6 would be offered soonish by the ASF, and I don't really want to send him to some other place offering binaries. Soonish. I'm still getting myself satisfied w.r.t. the binaries, have been working allot on VC8 here. Are there plans to release them soon, or do we wait for 2.2.7 and a settled fastcgi interface? That's one possibility, remember modperl has issues too, which is what really makes me apprehensive, at least if we pass them out without due warning of what's broke. Bill
Thoughts on Camillia in openssl binaries?
Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: William A. Rowe, Jr. wrote: Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill Seems reasonable in anticipation of it becoming supported in FireFox 3. Yes, that seems like a measurable target. It's nice to be ahead of the curve. FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. Good to know, thanks! On a slightly-related note; it might also be a good change to statically link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. Are you factoring in the cost of statically linking it also to mod_deflate? Consider also anyone using either the compression or decompression side of zlib1.dll from perl/mod_perl, php, python etc. You know from my deployment of awk.exe for the installer that I'm pretty intolerant of bloat, I think rle compression (which is always available) or no-compression gets used for SSL in most cases anyway. Many Windows users delete zlib1.dll and never notice its absence. Well people who randomly delete dll's certainly get what they ask for, we install it in the httpd/bin tree, not on their system32 or somewhere equally offensive. But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. PERL Configure VC-WIN32 enable-camellia zlib --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib FYI the ASF's build hard-links it this way (zdll.lib instead) which ensures we throw away the zlib-dynamic stubs (and eliminate some race and processing-time performance hits), so there is that factor, too. I sort of doubt we'll see any savings when you factor deflate and openssl together? The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is.
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: William A. Rowe, Jr. wrote: The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the security flaw in zlib argument would seem to apply to both equally. Both static or both dynamic would be more consistent. This was 2.0 that compiled in the subset of zlib sources directly. 2.2 should (and I'll fix this if I'm wrong) be linked to zlib1.dll
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: William A. Rowe, Jr. wrote: But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic and zlib1.dll is missing. The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the security flaw in zlib argument would seem to apply to both equally. Both static or both dynamic would be more consistent. You were right, we weren't linking to zdll.lib for mod_deflate, I'll be fixing that shortly, and working up the two patches to share, one for the APR_NO_FILE tweak, one for the stderr quirk with modperl. Had to push out these binaries first, and also now am struggling very deep inside MSVCR80/OpenSSL/ActiveState Perl on x64 and a host of bugs that some of the perl packages have, assuming they can pack pointers into int's and back out again. Sorry that mess left me distracted from the issues you raised for most of this week. Bill
Re: [PATCH 43415] Logging remote port.
Magnus Bodin wrote: A standalone sniffing box should be the best solution to this, I guess. That does NOT store the content. Ideally, until you note that if this machine is the SSL endpoint it's the only one with any privilage to put 2+2 together. Both a good and bad thing depending on what you are trying to accomplish. No problem with the patch (I too found %R sort of funky but... what else?) This is insane. We don't disagree :)
[Fwd: Re: [Fwd: Re: Thoughts on Camillia in openssl binaries?]]
Feedback from Ben via legal-discuss, since his httpd-dev list seems to have fallen over and can't get up. Bill ---BeginMessage--- William A. Rowe, Jr. wrote: A thread from [EMAIL PROTECTED], we are considering adding a newer algorithm to a binary 0.9.8 build of openssl. Introduces a patent question, with what is almost but not quite a complete grant of license. Looking for any feedback if this would concern us, since Tom raises the point that it gets interesting with Firefox 3 possibly using this algorithm. I should point out that just because some loon contributes an algorithm to OpenSSL doesn't mean you need to implement it. If there's any encumbrance, then I see even less reason to implement (less than none, that is). Bill Subject: Re: Thoughts on Camillia in openssl binaries? From: Tom Donovan [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 16:19:55 -0400 To: dev@httpd.apache.org To: dev@httpd.apache.org William A. Rowe, Jr. wrote: Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill Seems reasonable in anticipation of it becoming supported in FireFox 3. FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. On a slightly-related note; it might also be a good change to statically link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. I think rle compression (which is always available) or no-compression gets used for SSL in most cases anyway. Many Windows users delete zlib1.dll and never notice its absence. PERL Configure VC-WIN32 enable-camellia zlib --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib -tom- - DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See http://www.apache.org/licenses/ for official ASF policies and documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff ---End Message---
Re: OpenSSL compression (Windows)
Tom Donovan wrote: A case can be made for not enabling OpenSSL compression on Windows. If both parties to an SSL connection support compression, it is used for everything on the connection without regard to whether the content is compressible. Already-compressed data; like .jpg, .gif, .png, .zip, .tgz, .jar, and any content filtered by mod_deflate are re-compressed. This uses non-trivial CPU cycles for no (or slightly negative) benefit. Testing with some current browsers (FireFox 2.0.0.7, IE 6.0.2800.1106, IE 7.0.6000.16512, Opera 9.23) shows that none support TLS compression, even though they all have gzip capability - so there is not currently any issue with browser requests. Agreed, I think we need to get a handle on this within mod_ssl itself. The problem is when Apache is configured to proxy via https to another Apache server. If both servers have OpenSSL compression enabled, everything will be compressed (or re-compressed). If both OpenSSL libraries support compression, there is no apparent way to override this behavior. Previously, deleting zlib1.dll would accomplish this - but now deleting zlib1.dll will disable mod_deflate as well. Not on win32, all the binaries I've created are --enable-zlib, never --enable-zlib-dynamic. On 0.9.7 this was all irrelevant of course. Since mod_deflate can be tailored to compress appropriate content per request, the need to have compression at the connection level seems to be an unusual one. Perhaps those few folks who do want this could rebuild OpenSSL with compression enabled rather than shipping OpenSSL with it enabled. Keep in mind w.r.t. the win32 distribution, we need it enabled to support compression of ajp streams, ftp data streams etc. You are right about missing the context of compressibility, it would be very nice if after packing up 64k and realizing little or no benefit, if openssl would back off and decide to ship off the contents without compression. Because the feature is I agree for https that mod_deflate works out better than built in compression, so perhaps on a protocol level, beyond SSL Enable, we need some 'SSL Enable nodeflate' sort of choice that can be dropped into an https vhost, leaving it enabled, for example on an FTP Implicit SSL vhost. Bill
Re: [EMAIL PROTECTED] Apache Win32 Binary, mod_perl and mod_fcgid working
Steffen wrote: To inform you. We at http://www.apachelounge.com made a binary available which works with mod-perl and mod-perl etc. How did the perl-framework regression tests look; and which patch did you happen to use? Or is this the cobbled-together 2.2.6 + smattering of 2.2.5 sources? I'd personally encourage anyone who didn't need piped logs to hold back at 2.2.4 till there's a 2.2.7 ready to fly. Bill
Re: [EMAIL PROTECTED] Apache Win32 Binary, mod_perl and mod_fcgid working
Nick Kew wrote: On Tue, 25 Sep 2007 16:20:00 -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Steffen wrote: To inform you. We at http://www.apachelounge.com made a binary available which works with mod-perl and mod-perl etc. How did the perl-framework regression tests look; and which patch did you happen to use? Or is this the cobbled-together 2.2.6 + smattering of 2.2.5 sources? Presumably it could be something as simple as 2.2.6 with older APR. Or the relevant hacks to the thrid-party modules in question. Actually no, the flaw here in relation to modperl lies in mpm_winnt combined with perl combined with Microsoft's MSVCR[T|70|71|80].dll. The fcgid-type issues were a result of the newest APR which is what you must be thinking of. Bill
Re: 2.2.7
Jim Jagielski wrote: I'd like for us to consider a release of 2.2.7 in October to address the Windows file handle issues as well some other fixes that would be useful to get out quickly... How about 2 :) I expect to have Windows fixes ready to backport next week after the perlfolk confirm my suggested fixes for pseudo-standard I/O :) So it was my hope to release APR 1.2.12 quite quickly (no apr-util expected but that doesn't mean it wouldn't see some improvements that merit a release), and httpd 2.2.7 promptly. I've been shrinking patches to the minimum LoC to change/review/release and will commit today. I'd love to see another 2.2.8 with more bug fixes late in October or very early November, so that it's the 'best version available' and there would be very little push to make 2.2 better, but shift a bunch of energy to getting somewhere towards 2.4.x or hacking on the Amsterdam branch during our ApacheCon month. Bill
[Fwd: DO NOT REPLY [Bug 43491] New: - Piped ErrorLog regression: two piped program started, one attached to tty]
In the current log.c code, although the write-end of an initial error
logger is still held by the parent --- until the second logger process
has kicked off. It seems someone's inherited that write end. I have
a two line patch attached that
Needs some review before we kick off 2.2.7 into the real world, since
we close that write end of the logger right after we've launched the
logger. Wondering if this might not be a prefork, worker or event mpm
specific failure case.
This patch wasn't for this bug, it was strictly for common sense, but
I'm wondering if it doesn't have a side effect of solving the bug;
Bill
Index: server/log.c
===
--- server/log.c (revision 579397)
+++ server/log.c (working copy)
@@ -414,6 +414,12 @@
unable to replace stderr with error_log);
}
else {
+/* We are safer having only a single apr_file_t reference
+ * to the new main error logging stream
+ */
+apr_file_close(s_main-error_log)
+s_main-error_log = stderr_log;
+
/* We are done with stderr_pool, close it, killing
* the previous generation's stderr logger
*/
---BeginMessage---
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=43491.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43491
Summary: Piped ErrorLog regression: two piped program started,
one attached to tty
Product: Apache httpd-2
Version: 2.2.6
Platform: Other
OS/Version: AIX
Status: NEW
Severity: normal
Priority: P2
Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Pb was reproduced with 2.2.6 on AIX and Solaris.
Once piped log are configured (ex with rotatelogs), if you start Apache, you
will find two copies of the errorlog piped program:
- one has been started a few seconds prior to the second one
- the first one has parent pid=1 (not httpd) and is attached to your tty
Example below:
UID PIDPPID CSTIMETTY TIME CMD
root 1761522 1 0 18:28:05 - 0:00 httpd -k start
1892358 1761522 0 18:28:05 - 0:00 httpd -k start
root 1077456 1 0 18:28:02 pts/12 0:00 rotatelogs errors.%Y%m%d 86400
root 2170970 1761522 0 18:28:05 - 0:00 rotatelogs errors.%Y%m%d 86400
Since the first one is attached to your tty, you can no longer exit your ssh
connection easily nor automate things with remote shell commands
Located the pb in server/log.c: latest revision commited in 2.2.x branch
introduced the regression
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/server/log.c?
r1=569542r2=570451diff_format=h
Note: if first piped program is killed, no prob since the second one is the
one doing the job
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---End Message---
Jose's recent location test/failures
Jose wrote Re. New test: subrequests and content negotiation on Fri, 10 Aug 2007 03:44:49 -0700 The test consists on overloading the charset to utf-8: AddType text/html; charset=utf-8html/htm I believe the mistaken assumption is that charset can be used in this way. AddCharset should be used in this case. If no AddCharset is applied, AddDefaultCharset takes over. http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addcharset http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset Is that the origin of this observed 'flaw'?
Re: 2.2.7
Steffen wrote: There is the ASF statement/promise: Modules compiled for Apache 2.2 should continue to work for all 2.2.x releases. ***SHOULD*** is the operative word. There are always exceptions. I have a half dozen examples where I've abused the microsoft foundation classes in my code elsewhere, which have been broken by internal changes. Why? Because I dug into the internals instead of staying at the API's documented presentation layer. Of course, this was the only way I could use the MFC's functionality to accomplish what I was trying to do, so I'd balanced the danger of leveraging the internals against the benefits of tweaking the internals. Exploiting a flaw doesn't make it part of the API contract. ABI was not broken, and in fact won't be broken again with my proposed correction. In this case, we have two assumptions, that win32 handles are 'special things' which should behave differently than unix stdin/out/err when the APR refactoring had intended to make that not-the-case. And that you can always emit errors to stderr and record them somewhere, while with the old piped logging code (on ANY platform!) this was not so. Both flaws are corrected, the fallout, IMHO, is a tiny fraction of the user base but must be addressed for those users promptly in another iteration. That's how open sources work. FWIW there is another bit of fallout from keeping a usable stderr stream available at all times; c.f. Bug 43491 which I'm also analyzing for a solution by 2.2.7. So I expect that modules have *not* to be new compiled. It is quite confusing for our users en authors have to maintain in most cases up to 4 versions. What about the Magic Number ? I agree that due to these corrections, the MMN must be bumped with 2.2.7, thank you for raising that point! Btw. I guess (when I see the downloads) already a few thousands (production) sites are running the 2.2.6 version from the ApacheLounge*. Not a single problem report received, all running well including mod_perl and other mods which are failing with the ASF build. Equate downloads with production users? A tiny fraction from the feedback I've received, the majority of windows users who've spoken to me via email, at conferences etc are using windows for two purposes, testing/staging, and learning. There are certainly very robust windows users in production, but those don't correspond to the number of downloads you observe. But that's a fraction of the hundreds of thousands of hits that /dist/httpd/ takes per release, and we can't even most mirror activity! So I'm sure from your downloaders' perspective all is well, but the vast majority looking to httpd for the sources and binaries wouldn't be served by ignoring them. So for this moment the Windows Community has no need to hurry a new 2.2.7. We are also a little afraid that same things can happen as with the unusually closely 2.2.5==2.2.6 process, a broken build. s/the/your/ -- Good to hear, although as Tom suggests - the patches he provided you are 'mysterious' :) When he (and I) thoroughly understand the corrections and the reason they are the 'right' thing, we'll both be satisfied that it's a good thing for -all- users to adopt the patches. This is the process of /developer/ community review, a major shortcoming of many third party offerings (and some commercial products, for that matter). Tom's done a great job of clarifying this to users downloading the package, but I'm afraid your messages aren't so on-target. AFAIK the build was not broken, do you know something I don't? I've tested ./configure; make and nmake -f Makefile.win against a host of versions and OS's and don't recall any failure. Code developed under scrutiny of your peers (in the win32 case, such as Tom, Jorge, Mladen, Randy, etc - even myself) is what the ASF offers, as opposed to what AL has up for download mislabeled as 2.2.6. I don't mean users' testing and observation, I mean people who understand the internals. When your patch happens to work (and you aren't sure why) the first question is to dig deeply, and consult your peers, which is what Tom is engaged in.
Re: 2.2.7
Steffen wrote: I want to give attention to http://bahumbug.wordpress.com/2007/09/07/apache-226/ May be agood time to reconsider the depency for example with APR. Actually, I'm a fan of that idea - but not in the httpd 2.2.x cycle. It would be great to see 2.4.0 (3.0.0?) presume the latest APR 1.3.x flavor. If a bug's fixed entirely by APR, why not just grab the freshest APR? Of course you can do that right now, and in many distributions they do (e.g. most OS distributors now have separate apr, apr-util and httpd rpms, packages or depots). I hope we get there some day soon :)
Re: svn commit: r579777 - /httpd/httpd/branches/2.2.x/STATUS
[EMAIL PROTECTED] wrote: + * mod_proxy_ajp: Ignore any ajp13 flush packets that we may + receive before we send headers. + Trunk version of patch: +http://svn.apache.org/viewvc?view=revrevision=579707 + Backport version for 2.2.x of patch: + Trunk version of patch works (minus CHANGES conflict) + +1: jim Are any tomcat or other ajp agents trying to push out 100 CONTINUE style responses? Are we properly eating them (and sending out the appropriate ones ourselves?)
Re: [Fwd: DO NOT REPLY [Bug 43491] New: - Piped ErrorLog regression: two piped program started, one attached to tty]
Ruediger Pluem wrote: On 09/26/2007 07:30 PM, William A. Rowe, Jr. wrote: In the current log.c code, although the write-end of an initial error logger is still held by the parent --- until the second logger process has kicked off. It seems someone's inherited that write end. I have a two line patch attached that Funny. Two people getting to the same patch independently :-). So yes, I think your patch does the correct thing. Needs some review before we kick off 2.2.7 into the real world, since we close that write end of the logger right after we've launched the logger. Wondering if this might not be a prefork, worker or event mpm specific failure case. I don't think so. I don't think so, either, this licks it. I do believe we have one last bug in mpm_winnt to solve, because with the state of my (heavily-patched) trunk, I'm arriving with stderr_file of NULL in the ap_open_logs, and they should already have a static stderr_file. This is in the win32 child, and not the parent. Still debugging, but go ahead and commit your patch; tag it up for backports. You already have my +1 that it's the right fix. Bill
Re: Win32 httpd 2.2.6 installer missing mod_auth.h?
Graham Dumpleton wrote: Is this an oversight in the packaging up of Win32 installer, or is the presumption that one can use this package to compile modules against which need auth provider support wrong? Researching; I suspect that mod_auth.h isn't propagated into the include/ directory by the windows build. We should probably cut out all of the -I../modules/foo references and drop in copy targets across the board to move any public include to the top level include/ tree. Once the build deposits them all into include/, everything will be happy. The other question of course, did these public includes ever belong in the modules/ tree in the first place?
Re: 2.2.7
Roy really said everything necessary, I hesitated to even respond to you. But I'll offer this so that my frustration is perfectly clear and we (you and I, and for other devs in relation to other service providers as well) can coexist peacefully. Steffen wrote: Tom's done a great job of clarifying this to users downloading the package, but I'm afraid your messages aren't so on-target. We are a team in this matter. We adjusting who is posting what, and instruct each other. So all on-target. Planned communication. Then you missed the point entirely. You spammed to users@ and dev@ with; To inform you. We at http://www.apachelounge.com made a binary available which works with mod-perl and mod-perl etc. That's it. No clarification, nothing w.r.t. the fact that this was no longer Apache 2.2.6 but a hybrid with some fixes that both improve and regress the server. It will be good for some, bad for others and they don't know what they are getting from your spam. I offered; I'd personally encourage anyone who didn't need piped logs to hold back at 2.2.4 till there's a 2.2.7 ready to fly. Tom replied; Definitely! While this set of patches works, and therefore may yield some clues about the mod_perl problem - it remains unexplained *why* it works, so it cannot be considered trustworthy IMHO. There you have it. Tom's statement is clear; this is not more or less good than Apache httpd server 2.2.6, it's simply different, with pros and cons and we weren't sure why. There are certain users who can most definitely benefit from using this binary, and put up with any downside. But he makes that clear to users, you have not. This does not look like coordinated dialog. You do a disservice to the windows user community moving release candidate discussion from the forums where they belong (where the developers will read, react to and solve the problems) off to your own little cabana, rather than encouraging the reports to come right back here (or testers@) where something positive can quickly happen and the issue can be documented for future problem solvers and coders. You do a disservice to the windows user community not calling out the changes to your binaries, or adding the appropriate caveat emptor with respect to your announcement. Tom's done so, much to their benefit. (I'm speaking to your dev/users post, not to the text on your site). And finally, dev@ threads which are a /developer/ community effort are hijaaked to my personal inbox with statements such as I won't discuss code patches on a public list, here's the fix (paraphrasing). This is not helpful, in fact it's orthogonal to the Apache way of doing things. Those threads must be public, my mistakes, bugs, unintended consequences must be public, the solutions should be developed in public where modperl, fcgid, or any other module author can read them. That's how ASF development works. For example, Rudgier and I fixed the same bug at the same time today but - had one of us been off on vacation? It would have been fixed. With the dev discussion off in other places, others can't jump in and just get it solved. So on three counts above, yes, you've raised my frustration level. Your several thousand downloads is tiny overall in contrast to the total number of downloads of the windows package. Your users are (rightfully) quite thankful for the tips/help/service you provide. When suggestions on your forums pan out, and catch folks from google looking for just that answer, they should be appreciative and you can take pride in that. But the user community of httpd is [EMAIL PROTECTED], so don't confuse your niche with the Apache Windows user community or the Apache httpd project. Otherwise? I have /no/ issues with you, your team, AL or your community. Resources like the theserverside, xenocafe, tons of script example sites and of course ApacheLounge can be useful. You provide a service to your users, you let google scrape your site to bring traffic and confused users your way, and when the information posted is correct, everyone benefits. Roy points out he still takes issue with your domain name but I'll let you two work that out. It's the basic issues above on which you've begun to alienate yourself to the devs, repaired that frustration, and are now working to alienate yourself once again. Please address those specific issues, stop painting yourself a martyr for the Windows Users cause, and be welcome at both AL and here at Apache httpd project as a constructive participant. And stop with the spam already on users/dev - you don't see HP, Sun, IBM or even my employer spaming those lists with their products, do you? You are trying to create a community/peer resource/marketing engine etc etc etc, and having fun helping windows users in the process. Here at [EMAIL PROTECTED] we are trying to create a better server, and having fun in the process. As long as we don't splinter the effort of improving httpd server or
Re: Solution to apr stdio/msvc crt/service handles and logging
http://people.apache.org/~wrowe/apr-1.x-win32-nohandle.patch FYI - that one does not apply cleanly to apr-1.2 (it's trunk) if you want the easily applied flavor, that would be; http://people.apache.org/~wrowe/apr-1.2-win32-nohandle.patch The httpd patch applies with little pain.
Re: 2.2.7
Erik Abele wrote: Sure, we all have to pay our bills but you're overlooking a difference: Nick just replied to an inquiry offering his (and others services); he doesn't advertise any revenue-generating site after every release etc. etc... ;-0 Nick's comment didn't even mention he does this exclusively, he pointed out that there are a number of devs or organizations who can provide such services, and was *probably* letting the user know that the scope of their troubles was not going to elicit them enough purely voulenteer help. Again, Steffens contributions would be very welcomed *here* if this whole AL thing were just not that misleading - hey, with some effort he could e.g. help out constructively by building these binaries in a transparent and documented way *here* and we could even distribute them from apache.org/dist (plus mirrors) to help the win community even more! I want to be sure folks understand that the relabeling that Steffan and the AL team have already done went a long way to satisfying almost any of the project's possible concerns; the Feather is gone, disclaimers are posted. W.r.t. actually creating or distributing RC's, Colm's points went a long way to convince me they can be helpful --- that is if and only if the feedback gets back to where it might be useful to improving the s/w. Also note we only post binaries from committers; we can't/won't elicit or host them for add'l third parties. So for example, any committer is welcome to post updated sun .pkg's. But we wouldn't accept those from Sun. The origin of all of the files under http://www.apache.org/dist/httpd/ is from an Apache httpd project committer, each of whom is bound to a CLA (to resolve any possible IP/trust issues.) Bill
Re: x64 binary build instructions was Re: 2.2.7
Just for reference, Jorge's been instrumental in providing feedback that has made it easier (not trivial, yet) to build for x64 on Windows. There's actually a build log sitting off in http://people.apache.org/~wrowe/ if anyone is interested in how noisy the 64 bit builds still are on win32, we seem to have made hundreds of steps forward, but dozens of steps back in the most actively maintained code. Some real headaches; sizeof() and strlen() give you a size_t, which != int on a P64 platform like Windows (pointers == 64 bit, int/long == 32 bit). Most unicies we test on are either ILP64 or LP64, where at least the sizeof(long) == sizeof(void*). So with Jorge's and help from a few others, 2.2.6 builds quite nicely at the command line. To make the transition to the GUI requires some other steps, and I'm hoping these are simpler with 2.2.7 if I have a whole weekend to work them up before we start to TR. Bill Jorge Schrauwen wrote: My method is documentated here: http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 It is on my wiki todo list but school is keeping me busy + the weekends are going to some stuff that is earning me money. My method has evolved slightly but not very much just minor tweaks to make things easier for me :) On 9/27/07, *Justin Erenkrantz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sep 27, 2007 9:22 AM, Jorge Schrauwen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I could provide x64 binaries if there is interest in them. I usually push them out to my site within a week of the source release. I'm not 100% sure my method of creating them is the same as the ASF's but I can change my way if there is interest. Would you mind documenting your method? (Would the wiki be the right place for this?) Thanks! -- justin
Re: Solution to apr stdio/msvc crt/service handles and logging
Randy Kobes wrote: I'm currently rebuilding everything with VC 8 (the free version), and will report on that later. Yea - I discovered it's quite impossible to get msvcrt-linked activestate to cooperate with openssl compiled against msvcr80, and probably not against httpd+mod_perl against msvcr80. Even errors silently ignored before cause segfaults now when activestate tries to touch pseudo-posix files and visa versa because msvcr80 has all of the additional parameter checking. Really, building exclusively against either msvcr80 or msvcrt is the only way to go, and that includes all the bits. Bill
Re: svn commit: r580220 - /httpd/httpd/branches/2.0.x/modules/experimental/mod_case_filter.c
Sorry to jump over STATUS on this experimental change; I was seeing growing loop as I attempted to upcase a proxied back end response of LICENSE.txt, which repeated the opening part of the document over and over as it grew to the full response (from 39kb up to some 105kb). Does anyone see an issue with this backport (and does anyone want to put in the effort to do it well ;-) Bill [EMAIL PROTECTED] wrote: Author: wrowe Date: Thu Sep 27 22:01:56 2007 New Revision: 580220 URL: http://svn.apache.org/viewvc?rev=580220view=rev Log: Change to Experimental module to avoid an ever-expanding brigade, absorb the buckets we've consumed. Better ways to do this lurk here. Backport: r580206 Modified: httpd/httpd/branches/2.0.x/modules/experimental/mod_case_filter.c Modified: httpd/httpd/branches/2.0.x/modules/experimental/mod_case_filter.c URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/modules/experimental/mod_case_filter.c?rev=580220r1=580219r2=580220view=diff == --- httpd/httpd/branches/2.0.x/modules/experimental/mod_case_filter.c (original) +++ httpd/httpd/branches/2.0.x/modules/experimental/mod_case_filter.c Thu Sep 27 22:01:56 2007 @@ -89,7 +89,16 @@ APR_BRIGADE_INSERT_TAIL(pbbOut,pbktOut); } -/* XXX: is there any advantage to passing a brigade for each bucket? */ +/* Q: is there any advantage to passing a brigade for each bucket? + * A: obviously, it can cut down server resource consumption, if this + * experimental module was fed a file of 4MB, it would be using 8MB for + * the 'read' buckets and the 'write' buckets. + * + * Note it is more efficient to consume (destroy) each bucket as it's + * processed above than to do a single cleanup down here. In any case, + * don't let our caller pass the same buckets to us, twice; + */ +ap_briade_cleanup(pbbIn); return ap_pass_brigade(f-next,pbbOut); }
Re: Solution to apr stdio/msvc crt/service handles and logging
Randy Kobes wrote: The patched version built fine, and with the svn mod_perl2 sources, and perl-5.8.8 (ActivePerl 822), all the mp2 tests passed using VC++ 6. Great work! FYI I'm waiting on a third set of eyeballs before this is all committed. I'd especially appreciate any input from Tom w.r.t. the ease of adding APR_NO_FILE flags to apr_procattr_io_set() members whom are not allowed to have a handle at all, eg. how this works out with mod_fcgid and similar modules. Once that is done, I've been ready to commit. Bill
Re: x64 binary build instructions was Re: 2.2.7
On 9/28/07, *William A. Rowe, Jr.* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: So with Jorge's and help from a few others, 2.2.6 builds quite nicely at the command line. To make the transition to the GUI requires some other steps, and I'm hoping these are simpler with 2.2.7 if I have a whole weekend to work them up before we start to TR. The last one to build successfully from the vs.net http://vs.net IDE was 2.2.4 When you use manager / add target x64, it transforms many of the paths from .../Release to .../x64/Release, for example. Unfortunately not all and not consistently. I'm looking to make at least 95% of that process more smooth. (This is x64, I'm not talking about the default which should work just fine in 2.2.6, or quite close to it). Bill
Why permit --with-mpm=event ???
when [Sun Sep 30 17:19:47 2007] [crit] (70023)This function has not been implemented on this platform: Couldn't create a Thread Safe Pollset. Is it supported on your platform? it seems like a config-time test. Bill
Time to chop exports.c in half?
server/Makefile.in; export_files: tmp=export_files_unsorted.txt; \ rm -f $$tmp touch $$tmp; \ for dir in $(EXPORT_DIRS); do \ ls $$dir/*.h $$tmp; \ done; \ for dir in $(EXPORT_DIRS_APR); do \ (ls $$dir/ap[ru].h $$dir/ap[ru]_*.h $$tmp 2/dev/null); \ done; \ sort -u $$tmp $@; \ rm -f $$tmp Isn't it time, already, do do away with everything related to EXPORT_DIRS_APR in httpd 2.3-dev? (Obviously I wouldn't suggest changing anything for 2.2). It seems every modern OS should do a perfectly respectible job of binding dynamic libraries and their symbols without this extra, leftover cruft. Bill
Re: Adding timestamp to apache releases?
Boyle Owen wrote: Might it be an idea for 2.2.7? I like the idea of adding a date to each news item, be it on httpd.a.o, or our www.apache.org. +1. (Especially since the datestamps of our tarballs are several days prior to each release).
Re: Proxying OPTIONS *
Nick Kew wrote: RFC2616 tells us OPTIONS * is basically a simple HTTP ping, which suggests it could be at a 'lower' level than authconfig and always be allowed. If there is a reason to deny it, that could be by means of something analagous to TraceEnable. Insufficient. If we configure server-forced connection: upgrade/TLS we had better do so in the OPTIONS phase. So I agree that files don't apply. VirtualHost would. Location * should (and I'm not stating LocationMatch .* or Location /, but an explicit case which handles only OPTIONS). But I'm rather against breaking this in 2.2 to solve (what are, today) configuration quirks. Let's get this right for 2.4 and call out the change very clearly in (our overlong) CHANGES? I'm thinking of a new second-priority category after SECURITY:, e.g. CONFIG: or MUSTNOTE: so administrators who migrate aren't surprised. Bill
Re: Proxying OPTIONS *
Jim Jagielski wrote: TRACE also does not/should not trace to the filesystem. So, I think what we should do is use the existing architecture and have a quick_handler that checks for the OPTIONS * case and, if so, return DONE. You can't ignore the vhost, and preferably would handle the Location * as well in replacement for what Directory /docroot offered before. OPTIONS is a standard mechanism for handling the cart-before-the-horse problems of things like POST with ssl renegotiation. If we can correctly respond that you must Upgrade to SSL, or rehandshake now upon the initial OPTIONS query, their next POST won't fall into that trap. I am not sure, to be honest, what we should do for OPTIONS /foo if /foo is a protected entity... Reading 9.2: communication options available on the request/response chain... without implying a resource action or initiating a resource retrieval implies to me that ACL shouldn't even enter into it and should never return a 403... Which also implies that we should not honor any Limit for Options either... But if OPTIONS /uploads is a directory, while /uploads/ is a PUT-enabled web space, shouldn't we distinguish? w.r.t. auth, if they aren't logged in, /uploads/ doesn't include PUT. Now I'd totally agree that we want a smarter API for OPTIONS to allow resources to look at the auth results to decide 'yea, PUT's in that list' or 'nope, axe PUT'. Before I work on the fix (http://issues.apache.org/bugzilla/attachment.cgi?id=20902 seems just plain wrong to me), I'd like to see what Roy thinks about the above compliance points... Agreed.
Re: Proxying OPTIONS *
Jim Jagielski wrote: Hmmm on 2nd thought, map_to_storage is likely the more logical place. The answer, of course, is with the next version of apache, to finish abstracting out the filesystem at map_to_storage; where there is no DocumentRoot / FilePathAlias (e.g. alias) to force some other provider to serve the request, or fail :) httpd 2.2 remains far too filesystem-centric. Bill
Re: Proxying OPTIONS *
Joshua Slive wrote: On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But I'm rather against breaking this in 2.2 to solve (what are, today) configuration quirks. Let's get this right for 2.4 and call out the change very clearly in (our overlong) CHANGES? I'm thinking of a new second-priority category after SECURITY:, e.g. CONFIG: or MUSTNOTE: so administrators who migrate aren't surprised. Should be in this, rather sparse file: http://httpd.apache.org/docs/trunk/new_features_2_4.html But it's not a feature-per say. It's a bugfix, so the name new_features doesn't tell admins they have to adopt a change (new feature implies there's a goodie I can exploit if I choose to)... ...and hiding in docs isn't really the best place for major config-changing bullet points that will break their previously working, 2.2 server in some unexpected way. Bill
Re: Proxying OPTIONS *
Jim Jagielski wrote: Great! That's exactly what I needed to know. So it seems to me that a map_to_storage to check for the special case of '*' whereas present action for all other URIs is the best course of action. Provided it's vetted against the vhost (it is) and against location * then ++1, sounds great! (Note we could even shortcut everything after one location * mapping and not do the followup location * remapping - which occurs on all other patterns such as directory or proxy blocks!) Bill
Re: Proxying OPTIONS *
Joshua Slive wrote: On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Joshua Slive wrote: Should be in this, rather sparse file: http://httpd.apache.org/docs/trunk/new_features_2_4.html But it's not a feature-per say. It's a bugfix, so the name new_features doesn't tell admins they have to adopt a change (new feature implies there's a goodie I can exploit if I choose to)... Sorry, my little tiny contribution to this thread was less than useful. I meant the even more sparse: http://httpd.apache.org/docs/trunk/upgrading.html Woot :) Thanks.
Re: Proxying OPTIONS *
Jim Jagielski wrote: But, as I read it, the '*' in OPTIONS * does not really mean a Location *... in other words, it's not a URI per se. OPTIONS * asks for the capabilities of the server itself, independent of URI... At least, that's how I read it. There is no 'real' Location * There's a Location /*, or a LocationMatch .* But since Location is segment-delimited, Location * would only affect OPTIONS *. Bill
As we contemplate what to fix, and how to roll out 2.4 and 3.0
this is something really worth pondering; http://www.securityspace.com/s_survey/server_graph.html?type=httpdomaindir=month=200709servbase=YToyOntpOjA7czoxMzoiQXBhY2hlLzIuMC41OSI7aToxO3M6MTM6IkFwYWNoZS8xLjMuMzciO30=serv1=QXBhY2hlLzIuMi40 Give that some thought :) Bill
