Re: mod_authn_dbi
On Tue, 4 Mar 2003, Paul Querna wrote: so. What does everyone thing about including this in apache-2.1? Though a separate auth module tree was discussed for things like this - note that this module is very database agnostic - and I'd argue that it may be good for the base distribution. Dw.
Re: cvs commit: httpd-2.0/server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h
* [EMAIL PROTECTED] wrote: +AP_INIT_TAKE1(WindowsSocketsWorkaround, set_sockets_workaround, NULL, RSRC_CONF, + Set \on\ to work around buggy Winsock provider implementations of certain VPN or Firewall software), + hey, no need to double code. AP_INIT_FLAG exists ;-) nd -- print Just Another Perl Hacker; # André Malo, http://pub.perlig.de/ #
Re: cvs commit: httpd-2.0/server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h
+AP_INIT_TAKE1(WindowsSocketsWorkaround, set_sockets_workaround, NULL, RSRC_CONF, + Set \on\ to work around buggy Winsock provider implementations of certain VPN or Firewall software), + hey, no need to double code. AP_INIT_FLAG exists ;-) Well I guess that's just a matter of personal preference, I don't have strong feelings either way... took the cue from OtherBill. You might argue there is precedence for his style with Keepalive on|off. Any others think on|off is better dispensed with? Allan
mod_cache forward proxy
Currently CachEnable foo / will configure mod_cache to cache all forward proxy
responses. Seems to me we want to be a little more granular than that.
The following patch will enable the use of e.g. CacheEnable foo http:
to signify that just HTTP content should be cached. It also will allow
scoping to a particular server e.g. CacheEnable foo http://CacheOnlyThisServer/
which is useful for say a branch office proxy, where you want to cache content
from just the corporate server. Does this sound like a good idea? It will
of course break current forward proxy config files that are using CacheEnable foo / ,
but mod_cache *is* still experimental.
Index: mod_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.73
diff -u -d -b -r1.73 mod_cache.c
--- mod_cache.c 3 Feb 2003 17:52:59 - 1.73
+++ mod_cache.c 5 Mar 2003 18:52:13 -
@@ -95,7 +95,7 @@
apr_uri_t uri = r-parsed_uri;
char *url = r-unparsed_uri;
apr_size_t urllen;
-char *path = uri.path;
+char *path = r-uri;
const char *types;
cache_info *info = NULL;
cache_request_rec *cache;
Also, anyone have a good reason why we can't remove these
lines and allow mod_cache to serve default welcome pages?
/* DECLINE urls ending in / ??? EGP: why? */
if (url[urllen-1] == '/') {
return DECLINED;
}
Allan
ssl_engine_init.c compile warning
On APACHE_2_0_BRANCH, I'm seeing this compiler warning on RedHat 8.0.94 using gcc 3.2.2 with openssl-0.9.7-6: /bin/sh /export/home1/blair/Code/Apache/2.0/h/srclib/apr/libtool --silent --mode =compile gcc -pthread -g -O2 -I/usr/kerberos/include -Wl,-rpath,/opt/i386-linu x/db-4.1/lib -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_S OURCE -D_GNU_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -I/export/home1/blair/Cod e/Apache/2.0/h/srclib/apr/include -I/export/home1/blair/Code/Apache/2.0/h/srclib /apr-util/include -I/opt/i386-linux/db-4.1/include -I. -I/export/home1/blair/Cod e/Apache/2.0/h/os/unix -I/export/home1/blair/Code/Apache/2.0/h/server/mpm/prefor k -I/export/home1/blair/Code/Apache/2.0/h/modules/http -I/export/home1/blair/Cod e/Apache/2.0/h/modules/filters -I/export/home1/blair/Code/Apache/2.0/h/modules/p roxy -I/export/home1/blair/Code/Apache/2.0/h/include -I/usr/include/openssl -I/e xport/home1/blair/Code/Apache/2.0/h/modules/dav/main -prefer-pic -c ssl_engine_i nit.c touch ssl_engine_init.slo ssl_engine_init.c: In function `ssl_init_ctx_callbacks': ssl_engine_init.c:512: warning: assignment from incompatible pointer type Best, Blair -- Blair Zajac [EMAIL PROTECTED] Plots of your system's performance - http://www.orcaware.com/orca/
Re: coredumps on Linux
* Greg Ames ([EMAIL PROTECTED]) wrote : I mentioned this to other Apache folks around here and got some interesting reactions: * If we don't control this with a directive, we might violate the rule of least astonishment. For example, admins might be living with some buggy modules, and all of a sudden their disks fill up with unwanted coredump files. (Of course ServerRoot or CoreDumpDirectory would have to be writable by the httpd User for that to happen.) agreed; that really wouldn't be too pleasant! * If we do control this with a new directive and we don't make it very clear that this is just a Linux 2.4+ thing, users might think that turning on the new directive will magically solve all lack-of-coredump issues. It won't...there are Linux kernels 2.4, ulimit -c, permission issues, and the CoreDumpDirectory directive to name a few things, not to mention sysadmin stuff you have to do on FreeBSD and Solaris. One solution might be to control it with CoreDumpDirectory. If that's in the config file, one would assume the admin wants coredumps on failures. Once more, I have to agree - I only have CoreDumpDirectory enabled when I'm actually chasing down problems - I never enable it for production servers. However, we should document very clearly and obviously that setting CoreDumpDirectory will now produce cores even as root; it's entirely possible that some admins don't remove the directive because they *know* that we don't produce cores when running as root. I'm also curious about how admins with Linux production sites are dealing with seg faults etc. today if they are not getting coredumps. generally i run apache as a different user on a different port but with the exact config I want for 48 hours before taking it live, that usually sorts out any problems one way or another - if I do start seeing segfaults as root then the only usual recourse is firing up gdb and running in single process mode. This patch would be very useful in that respect. +1 from me to have CoreDumpDirectory be able to enable core dumps from root owned processes. Cheers, -Thom Thanks, Greg
[Apache 1.3] force-response-1.0 ignored for HTTP/1.1 requests
Hello, I am dealing with a broken proxy which understands chunked Transfer-Encoding on the proxy to server side, but does the wrong thing on the proxy to client side (it sends the Transfer-Encoding: chunked header from the server to proxy response, but sends the content unchunked). The easiest fix seems to be to always respond with an HTTP/1.0 response. I tried adding SetEnv force-response-1.0 Yes to the Apache server, but if Apache gets an HTTP/1.1 request (which it does in this case), it continues to send an HTTP/1.1 response. Additionally setting downgrade-1.0 didn't change anything. Is there a way to force Apache to send an HTTP/1.0 response even in response to an HTTP/1.1 request? I can send example transactions or open a bug if this would help. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: [Apache 1.3] force-response-1.0 ignored for HTTP/1.1 requests
[This question seems more appropriate for the users list rather than the developers list.] On Wed, 5 Mar 2003, Andrew Ho wrote: I am dealing with a broken proxy which understands chunked Transfer-Encoding on the proxy to server side, but does the wrong thing on the proxy to client side (it sends the Transfer-Encoding: chunked header from the server to proxy response, but sends the content unchunked). The easiest fix seems to be to always respond with an HTTP/1.0 response. I tried adding SetEnv force-response-1.0 Yes to the Apache server, but if Apache gets an HTTP/1.1 request (which it does in this case), it continues to send an HTTP/1.1 response. Additionally setting downgrade-1.0 didn't change anything. Is there a way to force Apache to send an HTTP/1.0 response even in response to an HTTP/1.1 request? The short answer: no. The long answer: using downgrade-1.0 will, in fact, force Apache to treat the request as if it was HTTP/1.0. It will therefore use only HTTP/1.0 features in the response. But it will still respond with HTTP/1.1 in the response line, since this just declares it as an HTTP/1.1 capable server; it doesn't mean the response itself uses HTTP/1.1 features. force-response-1.0 does cause apache to declare itself as HTTP/1.0, but it will only do so if the client request uses HTTP/1.0. force-response-1.0 does nothing if the client uses HTTP/1.1. See: http://httpd.apache.org/docs/env.html#special Joshua.
HTTP/1.1 requests get HTTP/1.1 responses even with downgrade-1.0(Was: force-response-1.0 ignored for HTTP/1.1 requests)
Hello, JSThe long answer: using downgrade-1.0 will, in fact, force Apache to treat JSthe request as if it was HTTP/1.0. It will therefore use only HTTP/1.0 JSfeatures in the response. But it will still respond with HTTP/1.1 in the JSresponse line, since this just declares it as an HTTP/1.1 capable server; JSit doesn't mean the response itself uses HTTP/1.1 features. Agreed on HTTP/1.1 declared in the response line; this is what RFC 2616 says should happen. However, I'm seeing behavior different from what you just described. That is, with downgrade-1.0, I still see Apache respond with HTTP/1.1 semantics. On a freshly built Apache 1.3.27 server with downgrade-1.0 set to 1 via a SetEnv command, I can issue this request: GET /test.cgi HTTP/1.1 Host: www.example.com Where test.cgi is just a CGI that prints out the string OK: #!/bin/sh echo Content-Type: text/plain echo echo OK Apache responds with chunked Transfer-Encoding and keeps the connection open, clearly HTTP/1.1 behaviors: HTTP/1.1 200 OK Date: Thu, 06 Mar 2003 03:33:42 GMT Server: Apache/1.3.27 (Unix) Transfer-Encoding: chunked Content-Type: text/plain 3 OK 0 JS[This question seems more appropriate for the users list rather than JSthe developers list.] Well, I thought of this list because this seems like either a bug, or a mismatch between the documentation and the actual behavior. I guess my original subject line was wrong, though, and I've corrected it. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
[STATUS] (apache-1.3) Wed Mar 5 23:45:08 EST 2003
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2003/02/04 19:08:59 $] Release: 1.3.28-dev: In development 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Current vote on 2 PRs for inclusion: Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: [EMAIL PROTECTED] Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore file-extension should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) * Salvador Ortiz Garcia [EMAIL PROTECTED]' patch to allow DirectoryIndex to refer to URIs for non-static resources. MID: [EMAIL PROTECTED] Status: Ken +1 (on concept), Lars +1 (on concept) * Brian
[STATUS] (httpd-2.0) Wed Mar 5 23:45:12 EST 2003
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2003/02/24 00:00:05 $] 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 and see what's there CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: CURRENT VOTES: * 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 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) 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 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: * RFC 2616 violations. Closed PRs: 15857. Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869, 15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137, 16138, 16139, 16140, 16142, 16518, 16520, 16521, jerenkrantz says: need to decide how many we need to backport and/or if these rise to showstopper status. * There is a bug in how we sort some hooks, at least the pre-config hook. The first time we call the hooks, they are in the correct order, but the second time, we don't sort them correctly. Currently, the modules/http/config.m4 file has been renamed to modules/http/config2.m4 to work around this problem, it should moved back when this is fixed. OtherBill offers that this is a SERIOUS problem. We do not sort correctly by the ordering arguments passed to the register hook functions. This was proven when I reordered the open_logs hook to attempt to open the error logs prior to the access logs. Possibly the entire sorting code needs to be refactored. * pipes deadlock on all platforms with limited pipe buffers (e.g. both Linux and Win32, as opposed to only Win32 on 1.3). The right solution is either GStein's proposal for a CGI Brigade, or OtherBill's proposal for Poll Buckets for Polling Filter Chains. Or maybe both :-) * All handlers should always send content down even if r-header_only is set. If not, it means that the HEAD requests don't generate the same headers as a GET which is wrong. * HP/UX 10.20: compile breakage in APR. Looks like it should be easy to fix, probably just some extraneous #include's that are fouling things up. PR: 9457 Jeff: See my reply and patch in the PR (and previous commit to stop using pipe as a field name). If patch is committed, we should be okay. I'll wait to see if the user tests the patch. Update by Jeff 20020722: I got an account on HP 10.20. It looks like some of the APR thread detection is screwed up. If we find pthread.h but we can't
Re: mod_authn_dbi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dirk-Willem van Gulik wrote: | | On Tue, 4 Mar 2003, Paul Querna wrote: | | |so. What does everyone thing about including this in apache-2.1? | | | Though a separate auth module tree was discussed for things like this - | note that this module is very database agnostic - and I'd argue that it | may be good for the base distribution. | | Dw. | I'm +1 on this as well. so.. whats the procedure to get this committed into the experimental/auth area? - --Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+ZtMgq3pgvCz4ZCcRAhxOAKCGFGcQCK1adQp8lQuWMgeneHRiHwCffHKG LlRjF9IBOqOJkPG4QQzPCcQ= =WCyZ -END PGP SIGNATURE-
Re: mod_authn_dbi
--On Wednesday, March 5, 2003 8:48 PM -0800 Ian Holsman [EMAIL PROTECTED] wrote: I'm +1 on this as well. so.. whats the procedure to get this committed into the experimental/auth area? As I said before, I don't believe these auth modules should be in the core - the people who are so interested in this can go create a new repository - call it httpd-auth or something. I've yet to be convinced that any of these belong in the main repository. It'd be much easier to grant commit access to people working on the auth modules if they lived in a separate repository. As it stands now, the main author of mod_authn_dbi would have to rely on others to commit fixes on his behalf. IMHO, that isn't a healthy way to foster the community. -- justin
