Re: Getting User and Group from custom httpd.conf
On Tue, Dec 16, 2003 at 02:43:20PM -0800, Stas Bekman wrote: I think that whatever logic we adopt for inheriting User and Group directives, someone will get bitten by it not doing the right thing, as they may not have their global httpd.conf set right. I agree. Suggestion #1: set APACHE_GROUP and APACHE_USER environment variables in your shell startup script, so it'll affect any Apache-Test runs I like this idea. Suggestion #2: Don't build/test as root. This is a bad practice. Build/test as a normal user and only 'su'/'sudo' when running 'make install'. Yeah I agree with the sentiment and usu. do this when installing software manually, but how does one install via CPAN shell? It seems that interface was made to be run as root. Am I missing something that would allow me to set it up to build/test as normal user and install as root? The other idea I've had is to gather this information via the processes already in place as well as perhaps Suggestion #1 and then present this information to the user in an interactive format such as done by HTTP::ApacheCookie. This allows users to specify alternate values if the system guesses incorrectly. I'd be willing to implement these changes if someone on the list can point me to the module and subroutine where I should be making them. Would the best place for these questions be in the TEST script? That would get tedious though when doing testing during development. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Getting User and Group from custom httpd.conf
William McKee wrote: [...] Suggestion #2: Don't build/test as root. This is a bad practice. Build/test as a normal user and only 'su'/'sudo' when running 'make install'. Yeah I agree with the sentiment and usu. do this when installing software manually, but how does one install via CPAN shell? It seems that interface was made to be run as root. Am I missing something that would allow me to set it up to build/test as normal user and install as root? All you need to do is to setup CPAN.pm to have its build dir under non-root directory, e.g. /tmp/.cpan. And the issue is solved. The other idea I've had is to gather this information via the processes already in place as well as perhaps Suggestion #1 and then present this information to the user in an interactive format such as done by HTTP::ApacheCookie. This allows users to specify alternate values if the system guesses incorrectly. Yes, yes, this is all planned to do. Hopefully next month. This won't solve the problem of running from under /root. Apache doesn't run under root and it won't be able to read files under /root, ever. So you have no choice but to build the project under some directory that user 'nobody' (or the one set via APACHE_USER/APACHE_GROUP) can read/write/execute. I'd be willing to implement these changes if someone on the list can point me to the module and subroutine where I should be making them. Would the best place for these questions be in the TEST script? That would get tedious though when doing testing during development. The plan is to adopt CPAN/FirstTime.pm to do the same for A-T. I'm planning to work on this somewhere next month. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Digest auth - no nonce/replay checking
Dirk-Willem van Gulik wrote: Unless I missed something we nicely issue a nonce during digest auth (based on r-request_time) - but when the reply comes in with an (Proxy-)Authenticate header we use the nonce provided by the client; and do not check if it was any where near reasonably likely that we issued it. So I guess - The release notes and the digest docs should propably contain a warning that we are not hardnened against certain replay attacks. - Long term we propably want to solve this; e.g. by using a hash over a static secret or somethign. I distinctly remember discussing this at the time - guess I didn't have the energy to fix it then :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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
Re: [PATCH] Introduce suppress-error-charset to 2.1
Anyone? I also attached a simple testcase for httpd-test.
You need to create perl-framework/t/htdocs/error_charset
directory.
BTW, where do I stand with regard to commit access to source
code area? I think theoretically its RTC like others but
practically I feel much more comfortable if someone can
review my patch.
Yoshiki Hayashi [EMAIL PROTECTED] writes:
This problem was brought up in Japanese user list some time
ago. In spite of the document, httpd 2.0 and 2.1 do not
have special meaning for suppress-error-charset environment
variable.
http://httpd.apache.org/docs-2.1/env.html#special
This feature was introduced to httpd 1.3 in revision 1.326
of http_protocol.c with the following log message:
| Add a new environment variable to keep the charset from being
| included on canned error documents. (Having it there make
| some browsers apply it to the redirect target document.)
|
| Reviewed by:Bill Stoddard, Jim Jagielski, Justin Erenkrantz, Cliff Woolley
http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_protocol.c
When you test this patch, be sure to turn off
AddDefaultCharset. It took me for a while to figure out who
is adding the charset again.
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.473
diff -u -r1.473 http_protocol.c
--- modules/http/http_protocol.c16 Nov 2003 02:09:13 - 1.473
+++ modules/http/http_protocol.c3 Dec 2003 19:16:44 -
@@ -2388,7 +2388,13 @@
r-content_languages = NULL;
r-content_encoding = NULL;
r-clength = 0;
-ap_set_content_type(r, text/html; charset=iso-8859-1);
+if (apr_table_get(r-subprocess_env,
+ suppress-error-charset) != NULL) {
+ ap_set_content_type(r, text/html);
+}
+else {
+ ap_set_content_type(r, text/html; charset=iso-8859-1);
+}
if ((status == HTTP_METHOD_NOT_ALLOWED)
|| (status == HTTP_NOT_IMPLEMENTED)) {
Index: perl-framework/t/apache/error_charset.t
===
RCS file: perl-framework/t/apache/error_charset.t
diff -N perl-framework/t/apache/error_charset.t
--- /dev/null 1 Jan 1970 00:00:00 -
+++ perl-framework/t/apache/error_charset.t 17 Dec 2003 23:11:32 -
@@ -0,0 +1,25 @@
+#
+# Test suppress-error-charset environmental variable
+#
+use strict;
+use warnings FATAL = 'all';
+
+use Apache::Test;
+use Apache::TestRequest;
+use Apache::TestUtil;
+
+t_debug Checking the SuppressErrorCharset environmental variable\n;
+
+plan tests = 2;
+
+check_error_charset(a_bogus_name, text/html; charset=iso-8859-1);
+check_error_charset(error_charset/a_bogus_name, text/html);
+
+sub check_error_charset {
+ my ($path) = shift;
+ my ($resp) = HEAD($path);
+ my ($content_type) = $resp-header(Content-Type);
+ my ($expected) = shift;
+ ok t_cmp($expected,
+ $content_type, Testing error response on $path);
+}
Index: perl-framework/t/conf/error_charset.conf.in
===
RCS file: perl-framework/t/conf/error_charset.conf.in
diff -N perl-framework/t/conf/error_charset.conf.in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ perl-framework/t/conf/error_charset.conf.in 17 Dec 2003 23:11:32 -
@@ -0,0 +1,9 @@
+##
+## suppress-error-charset test config
+##
+
+IfModule mod_env.c
+Directory @SERVERROOT@/htdocs/error_charset
+SetEnv suppress-error-charset true
+/Directory
+/IfModule
--
Yoshiki Hayashi
YA debug/diagnosis module for Apache 2+
short description: . implements a single process/single thread daemon running alongside Apache MPM (on Unix) to enable requests to be handled by an alternate mini-MPM . this can be useful for diagnosing web server problems . this can be useful for providing a simpler (unthreaded, predictable) debugger environment for testing/debugging non-MPM code without building a non-threaded MPM more info: http://www.apache.org/~trawick/mod_backdoor.txt http://www.apache.org/~trawick/mod_backdoor.c Comments or fixes are appreciated, of course. It was thrown together today and must be expected to have horrendous problems, but it works for me.
.htaccess contents
If someone knows this off the top of your head, I'd appreciate the answer: Is it true that there is no way to get the directives specified in .htaccess files? The main server config can be optained via the config_tree, but the .htaccess directives are passed to corresponding modules and aren't stored separately, correct? (Someone asked on the mod_python list how to get .htaccess contents, seems like the answer is to manually read it, and all the parent directory ones... I thought I'd check here, perhaps there is a better way.) Thanks! Grisha
Re: .htaccess contents
On Wed, 17 Dec 2003, Gregory (Grisha) Trubetskoy wrote: Is it true that there is no way to get the directives specified in .htaccess files? The main server config can be optained via the config_tree, but the .htaccess directives are passed to corresponding modules and aren't stored separately, correct? (Someone asked on the mod_python list how to get .htaccess contents, seems like the answer is to manually read it, and all the parent directory ones... I thought I'd check here, perhaps there is a better way.) That sounds right. --Cliff
[STATUS] (httpd-2.0) Wed Dec 17 23:45:10 EST 2003
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2003/12/17 15:53:10 $] Release: 2.0.49 : in development 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * just do an egrep on TODO, XXX and see what's there RELEASE SHOWSTOPPERS: PATCHES TO BACKPORT FROM 2.1 [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] * Add a hook (insert_error_filter) to allow filters to re-insert themselves during processing of error responses. Enable mod_expires to use the new hook to include Expires headers in valid error responses. This addresses an RFC violation. PR: 19794, 24884, and 25123. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_protocol.h?r1=1.84r2=1.85 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/http/http_protocol.c?r1=1.473r2=1.474 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/metadata/mod_expires.c?r1=1.48r2=1.49 +1: rederpj, trawick (requires minor MMN bump I believe) * mod_dav: Return a WWW-Auth header for MOVE/COPY requests where the destination resource gives a 401. http://cvs.apache.org/viewcvs/httpd-2.0/modules/dav/main/mod_dav.c.diff?r1=1.100r2=1.101 PR: 15571 +1: jorton, trawick * mod_dav_fs: Fix for dropping custom namespaces http://cvs.apache.org/viewcvs/httpd-2.0/modules/dav/fs/dbm.c.diff?r1=1.28r2=1.29 PR: 11637 +1: jorton, trawick * prefork: Fix slow graceful restarts on some platforms. http://cvs.apache.org/viewcvs/httpd-2.0/server/mpm/prefork/prefork.c.diff?r1=1.279r2=1.280 +1: jorton, trawick * parsed_uri.port is only valid iff parsed_uri.port_str != NULL. Old code simply checked if it was non-zero, not if it was *valid* http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c.diff?r1=1.247r2=1.248 +1: bnicholes, jim * Better descriptions for the configure --help output for some modules http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/config9.m4.diff?r1=1.17r2=1.18 +1: kess, trawick, nd, erikabele * Replace some of the mutex locking in the worker MPM with atomic operations for higher concurrency. server/mpm/worker/fdqueue.c 1.24, 1.25 +1: brianp, ianh * Rewrite how proxy sends its request to allow input bodies to morph the request bodies. Previously, if an input filter changed the request body, the original C-L would be sent which would be incorrect. Due to HTTP compliance, we must either send the body T-E: chunked or include a C-L for the request body. Connection: Close is not an option. [jerenkrantz2002/12/08 21:37:27] +1: stoddard, striker, jim -1: brianp (we need a more robust solution than what's in 2.1 right now), jerenkrantz (should be fixed, but I don't have time to do this) * Extend
[STATUS] (httpd-2.1) Wed Dec 17 23:45:15 EST 2003
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2003/12/12 10:24:59 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.0 : in development Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * just do an egrep on TODO or XXX in the source. * Review the PatchAvailable bugs in the bug database. Append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 CURRENT VOTES: * Promote mod_cache from experimental to non-experimental status (keep issues noted below in EXPERIMENTAL MODULES as items to be addressed as a supported module). +1: jim, bnicholes -0: jerenkrantz -1: stoddard There are a couple of problems that need to be resolved before this module is moved out of experimental. 1) We need to at least review and comment on the RFC violations 2) Resolve issue of how to cache page fragements (or perhaps -if- we want to cache page fragements). Today, mod_cache/mod_mem_cache will cache #include 'virtual' requests (but not #include 'file' requests). This was accomplished by making CACHE_IN a CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE filter. But now responses cannot be cached that include the effects of having been run through CONTENT_SET filters (mod_deflate, mod_expires, etc). We could rerun all the CONTENT_SET filters on the cached response, but this will not work in all cases. For example, mod_expires relies on installing the EXPIRATION filter during fixups. Contents served out of mod_cache (out of the quick_handler) bypass -all- the request line server hooks (Ryan really hated this. It is great for performance, but bad because of the complications listed above). jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla for mod_cache (see 'RFC 2616 violations' below). I think fixing them is a pre-requisite before it isn't experimental. * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Patches submitted to the bug database:
