[STATUS] (perl-framework) Wed Mar 5 23:46:05 EST 2003
httpd-test/perl-framework STATUS: -*-text-*- Last modified at [$Date: 2002/03/09 05:22:48 $] Stuff to do: * finish the t/TEST exit code issue (ORed with 0x2C if framework failed) * change existing tests that frob the DocumentRoot (e.g., t/modules/access.t) to *not* do that; instead, have Makefile.PL prepare appropriate subdirectory configs for them. Why? So t/TEST can be used to test a remote server. * problems with -d perl mode, doesn't work as documented Message-ID: [EMAIL PROTECTED] Date: Sat, 20 Oct 2001 12:58:33 +0800 Subject: Re: perldb Tests to be written: * t/apache - simulations of network failures (incomplete POST bodies, chunked and unchunked; missing POST bodies; slooow client connexions, such as taking 1 minute to send 1KiB; ...) * t/modules/autoindex - something seems possibly broken with inheritance on 2.0 * t/ssl - SSLPassPhraseDialog exec: - SSLRandomSeed exec:
[STATUS] (flood) Wed Mar 5 23:46:03 EST 2003
flood STATUS: -*-text-*- Last modified at [$Date: 2002/09/06 10:24:42 $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * More analysis and graphing scripts are needed * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is called easy reports (see flood_easy_reports.h). Furthermore, simple_reports and easy_reports both print out the current requesting URI line. Documentation that needs writing: * Documentation?
Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_init.c
[EMAIL PROTECTED] wrote: wrowe 2003/03/06 00:43:40 Modified:modules/ssl ssl_engine_init.c Log: DougM confirms Madhu's suspicions, this change was inadvertent. Reverting to no longer skip the first cert in the chain. Don't forget CHANGES and the PR number. ISTR that somebody submitted this patch already.
Re: 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)
Andrew Ho wrote: 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 I went through the same test this a.m. for a customer with some device that couldn't handle chunked response. For me, using BrowserMatch to set downgrade-1.0 eliminated the use of chunking in the response. $ ~/apache13inst/bin/httpd -V Server version: Apache/1.3.28-dev (Unix) Server built: Feb 12 2003 15:26:22 Server's Module Magic Number: 19990320:14 Server compiled with browsermatch GOBBLE downgrade-1.0 Here are two telnet sessions, one with GOBBLE for the user agent and one without: $ telnet 127.0.0.1 1 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. GET /cgi-bin/printenv HTTP/1.1 Host: local HTTP/1.1 200 OK Date: Thu, 06 Mar 2003 14:12:30 GMT Server: Apache/1.3.28-dev (Unix) Content-language: en, en Transfer-Encoding: chunked Content-Type: text/plain 2d9 DOCUMENT_ROOT=/home/trawick/apache13inst/htdocs GATEWAY_INTERFACE=CGI/1.1 HTTP_HOST=local PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/trawick/bin:/usr/local/bin:/home/trawick/newbin:/usr/lpp/cmvc/bin QUERY_STRING= REMOTE_ADDR=127.0.0.1 REMOTE_PORT=13587 REQUEST_METHOD=GET REQUEST_URI=/cgi-bin/printenv SCRIPT_FILENAME=/home/trawick/apache13inst/cgi-bin/printenv SCRIPT_NAME=/cgi-bin/printenv SERVER_ADDR=127.0.0.1 SERVER_ADMIN=[EMAIL PROTECTED] SERVER_NAME=cs390-1.raleigh.ibm.com SERVER_PORT=1 SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=ADDRESSApache/1.3.28-dev Server at cs390-1.raleigh.ibm.com Port 1/ADDRESS\n SERVER_SOFTWARE=Apache/1.3.28-dev (Unix) 0 ^] telnet quit Connection closed. $ telnet 127.0.0.1 1 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. GET /cgi-bin/printenv HTTP/1.1 User-agent: GOBBLE Host: local HTTP/1.1 200 OK Date: Thu, 06 Mar 2003 14:12:51 GMT Server: Apache/1.3.28-dev (Unix) Content-language: en, en Connection: close Content-Type: text/plain DOCUMENT_ROOT=/home/trawick/apache13inst/htdocs GATEWAY_INTERFACE=CGI/1.1 HTTP_HOST=local HTTP_USER_AGENT=GOBBLE PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/trawick/bin:/usr/local/bin:/home/trawick/newbin:/usr/lpp/cmvc/bin QUERY_STRING= REMOTE_ADDR=127.0.0.1 REMOTE_PORT=13588 REQUEST_METHOD=GET REQUEST_URI=/cgi-bin/printenv SCRIPT_FILENAME=/home/trawick/apache13inst/cgi-bin/printenv SCRIPT_NAME=/cgi-bin/printenv SERVER_ADDR=127.0.0.1 SERVER_ADMIN=[EMAIL PROTECTED] SERVER_NAME=cs390-1.raleigh.ibm.com SERVER_PORT=1 SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=ADDRESSApache/1.3.28-dev Server at cs390-1.raleigh.ibm.com Port 1/ADDRESS\n SERVER_SOFTWARE=Apache/1.3.28-dev (Unix) downgrade_1_0=1 Connection closed by foreign host. $
Re: mod_cache forward proxy
There is an entry in the STATUS file about adding regular expression
support for CacheEnable/CacheDisable, wouldn't regular expressions
provide this function and a whole lot more?
Allan Edwards wrote:
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.c3 Feb 2003 17:52:59 -1.73
+++ mod_cache.c5 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
--
Paul J. Reder
---
The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure.
-- Albert Einstein
Re: mod_cache forward proxy
Paul J. Reder wrote: There is an entry in the STATUS file about adding regular expression support for CacheEnable/CacheDisable, wouldn't regular expressions provide this function and a whole lot more? That could be the next step, did I hear a volunteer step forward ;-)
Re: mod_cache forward proxy
On Wed, Mar 05, 2003 at 05:23:27PM -0500, Allan Edwards wrote:
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
This isn't really a qualified comment as I haven't really contributed
as a developper (yet), but I'd still like to share it with you:
I've recently adapted the cache modules of a vanilla 2.0.44 source
tree in order to enable reverse proxy caching for an important but
slow performance site of ours that generates mostly static content with
dynamically served pages.
In the course of those changes (which include RFC violations) we
also stumbled across the fact that URLs ending in / are not cached.
We removed the corresponding lines - the change works fine so far and
we cannot see a reason why it shouldn't be done, either.
Cheers - Harry
pgp0.pgp
Description: PGP signature
Re: cvs commit: httpd-2.0/server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h
* Allan Edwards 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 ;-) Well I guess that's just a matter of personal preference, probably. My opinion in this case isn't strong either. Actually I wanted to exclude an oversight of the INIT_FLAG macro :) nd -- Wenn nur Ingenieure mit Diplom programmieren würden, hätten wir wahrscheinlich weniger schlechte Software. Wir hätten allerdings auch weniger gute Software. -- Felix von Leitner in dasr
Re: cvs commit: httpd-2.0/server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h
probably. My opinion in this case isn't strong either. Actually I wanted to exclude an oversight of the INIT_FLAG macro :) OK, point taken, thanks for the feedback Andre! Allan
Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_init.c
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14560 William A. Rowe, Jr. wrote: At 06:12 AM 3/6/2003, Jeff Trawick wrote: [EMAIL PROTECTED] wrote: wrowe 2003/03/06 00:43:40 Modified:modules/ssl ssl_engine_init.c Log: DougM confirms Madhu's suspicions, this change was inadvertent. Reverting to no longer skip the first cert in the chain. Don't forget CHANGES and the PR number. ISTR that somebody submitted this patch already.
[PATCH] fix fd leaks
Hi, here is a version of the patch in #17206 which removes the current the fd leaks. Most of these were introduced in this commit http://marc.theaimsgroup.com/?l=apache-cvsm=99531770520998w=2 though the pod leak has been around longer. I haven't checked whether the mod_file_cache change in that commit should be reverted as well. The patch is against 2.0 HEAD. Submitted by: Christian Kratzer, Bjoern A. Zeeb Index: modules/loggers/mod_log_config.c === RCS file: /store/cvs/root/httpd-2.0/modules/loggers/mod_log_config.c,v retrieving revision 1.99 diff -u -r1.99 mod_log_config.c --- modules/loggers/mod_log_config.c14 Feb 2003 04:17:34 - 1.99 +++ modules/loggers/mod_log_config.c6 Mar 2003 15:38:07 - @@ -1291,7 +1291,6 @@ could not open transfer log file %s., fname); return NULL; } -apr_file_inherit_set(fd); return fd; } } Index: modules/mappers/mod_rewrite.c === RCS file: /store/cvs/root/httpd-2.0/modules/mappers/mod_rewrite.c,v retrieving revision 1.148 diff -u -r1.148 mod_rewrite.c --- modules/mappers/mod_rewrite.c 1 Mar 2003 18:35:50 - 1.148 +++ modules/mappers/mod_rewrite.c 6 Mar 2003 15:38:08 - @@ -3429,7 +3429,6 @@ file %s, fname); exit(1); } -apr_file_inherit_set(conf-rewritelogfp); } return; } Index: server/log.c === RCS file: /store/cvs/root/httpd-2.0/server/log.c,v retrieving revision 1.130 diff -u -r1.130 log.c --- server/log.c10 Feb 2003 16:27:28 - 1.130 +++ server/log.c6 Mar 2003 15:38:08 - @@ -320,8 +320,6 @@ ap_server_argv0, fname); return DONE; } - -apr_file_inherit_set(s-error_log); } return OK; Index: server/mpm_common.c === RCS file: /store/cvs/root/httpd-2.0/server/mpm_common.c,v retrieving revision 1.103 diff -u -r1.103 mpm_common.c --- server/mpm_common.c 3 Feb 2003 17:53:19 - 1.103 +++ server/mpm_common.c 6 Mar 2003 15:38:08 - @@ -410,6 +410,10 @@ apr_sockaddr_info_get((*pod)-sa, ap_listeners-bind_addr-hostname, APR_UNSPEC, ap_listeners-bind_addr-port, 0, p); +/* close these before exec. */ +apr_file_unset_inherit((*pod)-pod_in); +apr_file_unset_inherit((*pod)-pod_out); + return APR_SUCCESS; } Index: server/mpm/worker/pod.c === RCS file: /store/cvs/root/httpd-2.0/server/mpm/worker/pod.c,v retrieving revision 1.7 diff -u -r1.7 pod.c --- server/mpm/worker/pod.c 3 Feb 2003 17:53:26 - 1.7 +++ server/mpm/worker/pod.c 6 Mar 2003 15:38:08 - @@ -76,6 +76,10 @@ */ (*pod)-p = p; +/* close these before exec. */ +apr_file_unset_inherit((*pod)-pod_in); +apr_file_unset_inherit((*pod)-pod_out); + return APR_SUCCESS; }
Re: coredumps on Linux
Thom May wrote: 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. yep. 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. ouch! 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 much for the feedback, Thom. It's reassuring to hear from someone who is running a production site on Linux. I hate wasting time when debugging problems because we don't have first failure data capture, so I hope this will help. I also heard from Ian H. He mentioned that iptables can forward port 80 to a high listening port so you can run as non-root. Interesting! Greg
Re: coredumps on Linux
* Greg Ames ([EMAIL PROTECTED]) wrote : Thom May wrote: ouch! very ;-) 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 much for the feedback, Thom. It's reassuring to hear from someone who is running a production site on Linux. I hate wasting time when debugging problems because we don't have first failure data capture, so I hope this will help. Definitely; I'm looking forward to having it in the basic distro :-) I also heard from Ian H. He mentioned that iptables can forward port 80 to a high listening port so you can run as non-root. Interesting! not really a trick for a production system, but pretty nice for development for sure. Greg Cheers, -Thom
Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_init.c
Good to see that at least one more individual recognized the problem! Unfortunately with bugzilla, I have only an email addy, and don't see a name. In any case, Madhu's patch hit first, so that's the name I went with. Bill At 09:10 AM 3/6/2003, Jeff Trawick wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14560 William A. Rowe, Jr. wrote: At 06:12 AM 3/6/2003, Jeff Trawick wrote: [EMAIL PROTECTED] wrote: wrowe 2003/03/06 00:43:40 Modified:modules/ssl ssl_engine_init.c Log: DougM confirms Madhu's suspicions, this change was inadvertent. Reverting to no longer skip the first cert in the chain. Don't forget CHANGES and the PR number. ISTR that somebody submitted this patch already.
Current HEAD of httpd-2.0
fails to configure with the following error: Construct makefiles and header files... creating config_vars.mk updating cache ./config.cache creating ./config.status creating docs/conf/httpd-std.conf sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating include/ap_config_layout.h sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating support/apxs sed: file conftest.s3 line 3: Unknown command: `A' sed: file conftest.s2 line 71: Unterminated `s' command creating support/apachectl sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating support/dbmmanage sed: file conftest.s3 line 3: Unknown command: `A' sed: file conftest.s2 line 71: Unterminated `s' command creating support/envvars-std sed: file conftest.s3 line 3: Unknown command: `A' sed: file conftest.s2 line 71: Unterminated `s' command creating support/log_server_status sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating support/logresolve.pl sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating support/phf_abuse_log.cgi sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating support/split-logfile sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating build/rules.mk sed: file conftest.s2 line 71: Unterminated `s' command sed: file conftest.s3 line 3: Unknown command: `A' creating include/ap_config_auto.h include/ap_config_auto.h is unchanged Apr and apr-util are both uptodate, and all source trees have been 'make extraclean buiconf'ised. Cheers, -Thom
Re: [STATUS] (httpd-2.0) Wed Mar 5 23:45:12 EST 2003
I noticed a couple of these notes apply to me in one way or another so figured I'd chime in with some thoughts; * Rodent of Unusual Size ([EMAIL PROTECTED]) wrote: APACHE 2.1 STATUS: -*-text-*- [snip] TODO ISSUES REMAINING IN MOD_SSL: * In order to use a DSO version of mod_ssl we have to link with -lssl and -lcrypto. A workaround is in place right now where the entire EXTRA_LIBS macro is being appended to the objects list, but this is a hack. We should either revamp the APACHE_CHECK_SSL_TOOLKIT autoconf function or come up with some other autoconf checks to search for libssl and libcrypto and properly add them to mod_ssl's link flags. I think the patch I sent to the list (which is awaiting comments BTW) will address this, but this is unconfirmed. Namely, my patch uses only LDFLAGS tweaks for library paths, and then only if --with-ssl=path is specified. For the remainder, autoconf's normal mechanisms for library probes and linker configuration are used. Ie. the actual probing for libssl and libcrypto is handled by the AC_CHECK_LIB() macro and so autoconf alone works out what flags are required from then on for linking apache. I'm wondering if the above problem is a consequence of us explicitly setting linker syntax and not letting autotools do their job properly? Anyway, the patch is there if someone wants to see if it helps with this issue as well. * session cache store should be pluggable I'd like to speak with the person who's behind this, as I'm waiting for my current openssl-configuration changes to be reviewed and ironed out before I submit a new session cache module supporting 'distcache' (www.distcache.org). I'm also wondering if on the openssl-side we need some kind of modularised approach to session caching rather than this duplicating of effort in openssl-based apps. Unfortunately that would probably raise the issue that the basic session caching interface is inadequate and some rewiring would be required first. I see worms oozing out of cans. Anyway, I'm happy to discuss this issue with whoever is behind it in case I can be of any help. * the shmcb code should just align its memory segment rather than jumping through all the safe memcpy and memset hoops I wrote shmcb and I don't think the person who wrote this quite understands why this jumping through hoops is done. Trying to align all the relevant data will cost more than just a few wasted bytes of storage, and I respectfully suggest that the safe accessors (which aren't speed-critical) would be easier to maintain. Again, I'm available to bash these ideas out if anyone's interested. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
Re: [PATCH] fix fd leaks
On Thu, 6 Mar 2003, Joe Orton wrote:
Hi,
Submitted by: Christian Kratzer, Bjoern A. Zeeb
...
-
-apr_file_inherit_set(s-error_log);
}
so now we are back to that point that needs further discussing.
Should we simply remove apr_file_inherit_set or explicitly call
apr_file_unset_inherit ? Simply removing works as long as defaults in
APR remain but there is still p.ex.:
if (!(flag APR_FILE_NOCLEANUP)){
that can again prevent the child_cleanup_fn from being set (seems to
unused in open at the moment).
It seems to me that the apr_file_inherit_set had been in because up
to including httpd 2.0.39 a bug in apr prevented _set/_unset from
working as expected (the 2^24 vs. 224 flag check).
Thus _set did the correct thing that _unset should have done.
If the _sets had been in for some specific reason we sould perhaps
use _unset.
So there needs to be further tracking on why the _sets had been
committed to apache code.
Comments ?
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
Re: 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, JTI went through the same test this a.m. for a customer with some device JTthat couldn't handle chunked response. For me, using BrowserMatch to JTset downgrade-1.0 eliminated the use of chunking in the response. Interesting. I confirmed on my setup that this works (answers my HTTP/1.1 query with an HTTP/1.0 request) for all incoming requests: BrowserMatch ^ downgrade-1.0 So I guess that is my workaround for the time being. But I'm still curious why this presumed equivalent does not work for any incoming requests: SetEnv downgrade-1.0 1 I browsed through mod_setenv_if.c and it sure looks to me like the BrowserMatch command should be functionally equivalent to the SetEnv command (including using 1 as the true value). Indeed, the documentation at http://httpd.apache.org/docs/env.html#special states that downgrade-1.0 and friends are invoked by defining environment variables, typically with BrowserMatch, though SetEnv and PassEnv could also be used. In src/main/http_request.c, the check for downgrade-1.on line 1218 just checks that ap_table_get(r-subprocess_env, downgrade-1.0) is true, which it should be in both cases. If I print out the environment in the test CGI being invoked, in both cases I see downgrade_1_0=1. But, when I put in some debugging statements, I see that in the BrowserMatch case, ap_table_get(r-subprocess_env, downgrade-1.0) == 1, but in the SetEnv case, that same statement returns NULL. 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: [PATCH] openssl configuration (v2)
--On Tuesday, March 4, 2003 6:43 PM -0500 Geoff Thorpe [EMAIL PROTECTED] wrote: Questions for apache gurus/code-reviewers; - AC_CHECK_HEADERS() appears difficult to coax into accepting additional include paths, so if --with-ssl=path is specified there appears no obvious way to have AC_CHECK_HEADERS() pick up those headers in (particularly if versions exist in system locations too and we want autoconf's tests to find the path versions in preference to any auto-detectable ones). I've left some comments in the acinclude.m4 changes about this. For now, I've made do with adding -I... to CFLAGS prior to AC_TRY_COMPILE, but I'm sure autoconf intended some other way of handling this. For one thing, is -I actually portable anyway? The existing code depends utterly on it but it would be nice to do away with it altogether. I think you mean adding -I... to CPPFLAGS not to CFLAGS. That should be portable and supported everywhere. It's a C preprocessor flag not a flag for the compiler. Autoconf will evaluate ac_compile which includes $CPPFLAGS. You should be able to use APR_ADDTO on CPPFLAGS for the explicit path case. (Since the user specified it, we always need to add it to CPPFLAGS.) - My changes use autoconf tests for openssl/ssl-c headers and libraries (existing code just looks for files but doesn't actually try to use them). As a result, linker flags like -ldl, -lsocket, -lnsl, -ldld, etc are needed in advance of these tests. I've added the obvious ones I know about so that this patch can be tested as-is, but ideally Apache's builtin tests (which are obviously OK because Apache links fine) should occur before the AC_CHECK_LIB()s for ssl and crypto. See Step 3 of my changes to acinclude.m4. A much easier route would be to include `$apr_config --libs` in that section. Those libraries would be in there. When we go to actually link, the libtool dependencies will have them there. But, you could add those to LIBS temporarily - just remove them when you are done trying to link. - The adjustments made to LDFLAGS at the end of the testing has been written to try and match the existing stuff, but I don't confess to know what the significance of $ap_platform_runtime_link_flag is so I'm working blind there. ap_platform_runtime_link_flag is '-R' on those platforms that need a special flag to indicate where to look at run-time for libraries. (Solaris is the predominate case.) Some platforms use '-rpath' as well. -L is not enough. - I'm tagging -DHAVE_OPENSSL or -DHAVE_SSLC directly onto CFLAGS rather than using anything like AC_DEFINE because the latter possibility would require HAVE_OPENSSL and HAVE_SSLC to be stubbed into an appropriate something.h.in file. If you prefer not to have such stuff polluting CFLAGS then please suggest an appropriate .in file for me to hook into. Why is having HAVE_OPENSSL or HAVE_SSLC in ap_config_auto.h a bad thing? I don't understand. Any/all feedback most welcome. Comments inline. Index: acinclude.m4 === RCS file: /home/cvspublic/httpd-2.0/acinclude.m4,v retrieving revision 1.136 diff -u -r1.136 acinclude.m4 --- acinclude.m417 Feb 2003 02:32:19 - 1.136 +++ acinclude.m44 Mar 2003 23:00:03 - @@ -320,7 +320,7 @@ dnl and then AC_TRY_LINK to test the libraries directly for the version, dnl but that will require someone who knows how to program openssl. dnl -AC_DEFUN(APACHE_CHECK_SSL_TOOLKIT,[ +AC_DEFUN(APACHE_CHECK_SSL_TOOLKIT_OLD,[ if test x$ap_ssltk_base = x; then AC_MSG_CHECKING(for SSL/TLS toolkit base) ap_ssltk_base= Just toss the old APACHE_CHECK_SSL_TOOLKIT. No need to keep the old version around. + dnl Step 5: run version checks + if test $ap_ssltk_type = openssl; then +saved_CFLAGS=$CFLAGS +if test x$ap_ssltk_inc != x; then + CFLAGS=$CFLAGS $ap_ssltk_inc +fi +AC_MSG_CHECKING(for OpenSSL version) +AC_TRY_COMPILE([#include openssl/opensslv.h], +[#if !defined(OPENSSL_VERSION_NUMBER) || OPENSSL_VERSION_NUMBER 0x0090609f +#error invalid openssl version +#endif], + [dnl Replace this with OPENSSL_VERSION_TEXT from opensslv.h? + AC_MSG_RESULT(OK)], Yes, it should indicate the version found somehow. I believe we did that before. I think it's worthwhile to have. Index: modules/ssl/config.m4 === RCS file: /home/cvspublic/httpd-2.0/modules/ssl/config.m4,v retrieving revision 1.11 diff -u -r1.11 config.m4 --- modules/ssl/config.m4 29 Mar 2002 07:36:01 - 1.11 +++ modules/ssl/config.m4 4 Mar 2003 23:00:05 - @@ -77,8 +77,13 @@ dnl # hook module into the Autoconf mechanism (--enable-ssl option) APACHE_MODULE(ssl, [SSL/TLS support (mod_ssl)], $ssl_objs, , no, [ APACHE_CHECK_SSL_TOOLKIT -AC_CHECK_FUNCS(SSL_set_state) -AC_CHECK_FUNCS(SSL_set_cert_store) +dnl These checks aren't really useful and
cgid on hp-ux - read hangs because shutdown doesn't close
I'm running into a problem with some code based on the mod_cgid module, on hp-ux. I've also submitted the underlying problem to comp.systems.hp.hpux. The problem is that the underlying cgi hangs on a read from stdin when there is actually no data left to be read. I can reduce this to a simple discrepency between HP-UX and other platforms, Linux being my example. On Linux, when the socket shutdown(sd, 1) is done by the sender, the read on the socket returns with eof. On HP-UX, this doesn't happen until the socket is actually closed. My code happens to be based on 2.0.40, though I've looked at the changes in 2.0.44 and they don't seem relevant (the changes are there to catch EINTR, but I don't see any way to trigger that). Any advice would be appreciated. Gary PS: I originally submitted this to the users list, where someone suggested I resubmit here. Ready-to-Run Software, Inc. The Industry's Leading Provider of Cross-Platform Software Services * email: [EMAIL PROTECTED] Gary Feldman fax : 1-978-692-5401 Ready-to-Run Software, Inc. voice: 1-978-251-5431 11 School Street www : http://www.rtr.com North Chelmsford, MA 01863 USA
Re: [PATCH] openssl configuration (v2)
Hi Justin, * Justin Erenkrantz ([EMAIL PROTECTED]) wrote: I think you mean adding -I... to CPPFLAGS not to CFLAGS. That should be portable and supported everywhere. It's a C preprocessor flag not a flag for the compiler. Autoconf will evaluate ac_compile which includes $CPPFLAGS. You should be able to use APR_ADDTO on CPPFLAGS for the explicit path case. (Since the user specified it, we always need to add it to CPPFLAGS.) I was just getting ready to launch into a spiel about how none of the documented flags seemed to be honoured by AC_CHECK_HEADERS and how I'd looked at the generated configure script to see that cpp invocation looked very different to compiler invocation, blah blah blah. Anyway, I will spare you that spiel because having double checked I see that you're absolutely right and I'm now wondering how I ended up so derailed in the first place. I guess something else must have been broken whilst I was trying that out and I never twigged. Anyway yes, putting the include paths into CPPFLAGS makes header checking work. Thanks :-) [snip] Apache's builtin tests (which are obviously OK because Apache links fine) should occur before the AC_CHECK_LIB()s for ssl and crypto. See Step 3 of my changes to acinclude.m4. [snip] A much easier route would be to include `$apr_config --libs` in that section. Those libraries would be in there. When we go to actually link, the libtool dependencies will have them there. But, you could add those to LIBS temporarily - just remove them when you are done trying to link. Well, this is exactly what I was looking for. Unfortunately it seems not to work as-is. What happens is that if I remove my explicit AC_CHECK_LIB() calls for dl, socket, nsl, etc and do the following; ... saved_LIBS=$LIBS LIBS=$LIBS `$apr_config --libs` AC_CHECK_LIB(crypto, SSLeay_version) AC_CHECK_LIB(ssl, SSL_CTX_new) LIBS=$saved_LIBS ... then strangely the -lcrypto and -lssl checks report success *yet* they do not find their way into the linker flags (so apache fails to link after compiling). I can only imagine 2 reasons for this; either my restoring of LIBS to its original form obliterates the result of the AC_CHECK_LIB() macros, or the fact the linker flags that -lcrypto and -lssl depend have disappeared (and didn't occur in AC_CHECK_LIB() form) mean that autoconf does away with -lcrypto and -lssl some point later. I suspect the former as the latter seems just too weird a possibility. ap_platform_runtime_link_flag is '-R' on those platforms that need a special flag to indicate where to look at run-time for libraries. (Solaris is the predominate case.) Some platforms use '-rpath' as well. -L is not enough. I figured it must be something of that sort from the existing code's comments, thanks for clarifying. I mainly wanted to be sure it wasn't producing something to compensate for the fact autoconf's own mechanisms weren't being used. Can I assume then that I'm right to parrot the existing code's production of the additional LDFLAGS entry if that flag is set? - I'm tagging -DHAVE_OPENSSL or -DHAVE_SSLC directly onto CFLAGS rather than using anything like AC_DEFINE because the latter possibility would require HAVE_OPENSSL and HAVE_SSLC to be stubbed into an appropriate something.h.in file. If you prefer not to have such stuff polluting CFLAGS then please suggest an appropriate .in file for me to hook into. Why is having HAVE_OPENSSL or HAVE_SSLC in ap_config_auto.h a bad thing? I don't understand. I didn't say it was a bad thing, on the contrary - I think it's a good thing, I just wasn't sure which (if any) .in file would have been the appropriate one. It's a big-ass tree of code that I have only very selective familiarity with. :-) Anyway, following your comments, I noticed that declaring the symbols in the top-level acconfig.h and running ./buildconf eventually propogating those values into ap_config_auto.h.in and everything works. I'm happy with that, is it what you had in mind? -AC_DEFUN(APACHE_CHECK_SSL_TOOLKIT,[ +AC_DEFUN(APACHE_CHECK_SSL_TOOLKIT_OLD,[ Just toss the old APACHE_CHECK_SSL_TOOLKIT. No need to keep the old version around. Yeah, but I'm leaving it like this while hashing out the patch details because it makes the diff readable (if you remove the old version and produce a diff, you'll see what I mean). +AC_MSG_CHECKING(for OpenSSL version) +AC_TRY_COMPILE([#include openssl/opensslv.h], +[#if !defined(OPENSSL_VERSION_NUMBER) || OPENSSL_VERSION_NUMBER 0x0090609f +#error invalid openssl version +#endif], + [dnl Replace this with OPENSSL_VERSION_TEXT from opensslv.h? + AC_MSG_RESULT(OK)], Yes, it should indicate the version found somehow. I believe we did that before. I think it's worthwhile to have. I'm all for it, but would rather not guess as to the preferred mechanism for slurping that text out of the header file (especially as we're not
introduce getword_conf_s?
We have a PR (16631) that mentions that at least one error log entry is not assigned to the appropriate error log (in 1.3). The warning is written by ap_getword_conf, which doesn't know anything about server_rec structures. I've discovered this by trying to forward port this feature. However, I'd really like to see this warning to go into 2.1 and here written to the right log. What do you think about introducing a wrapper around ap_getword_conf, called ap_getword_conf_s (or similar, suggestions welcome ;-)? It would take server_rec *s as a third argument and could write the warning into the right place. nd -- print Just Another Perl Hacker; # André Malo, http://pub.perlig.de/ #
Re: mod_authn_dbi
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 that sure would make it more difficult to do timely updates without cvs access. making a httpd-auth cvs auth repository makes sense to me. -chip
I surrender (.pdb for releases, no .dbg)
After spending many hours reviewing and actively using debug symbols for real customer incidents, I have formed some different opinions and wanted to share. I'm convinced that with the Win32 debugging tools (free to download) available today, there is exactly one benefit to .dbg files - Dr. Watson on WinNT can display backtraces. It's already possible to display those backtraces on the 98, ME, 2k and XP from .pdb files. That small benefit against the broken .pdb - binaries isn't worth that aggravation. For me to collect the symbols from the public releases, into a symbols store isn't possible today. The very act of rebase'ing (when extracting) the .dbg files breaks the original association between each binary and it's complete .pdb information file. The .dbg files are very lightweight flavors of (with much less info than) the comprehensive .pdb files. Anyone on WinNT can simply use WinDbg to bring up a crash dump created by Dr. Watson. At that point, it's trivial to look at the stack backtrace (complete with arguments) which is much richer than Dr. Watson provides by default. Of course a typical user won't understand either Dr. Watson or WinDbg, but would be happy to forward a user.dmp file. The .dbg files add nothing to what we get out of .pdb files in helping to triage such a report. So at this point, I'm ready to back out the .dbg file creation logic, leaving the .pdb logic for complete analysis of crash dumps of any given ASF build of the Apache releases. Unless anyone has any objection, I should get to this later tomorrow afternoon. Bill
Re: introduce getword_conf_s?
--On Thursday, March 6, 2003 11:41 PM +0100 André Malo [EMAIL PROTECTED] wrote: We have a PR (16631) that mentions that at least one error log entry is not assigned to the appropriate error log (in 1.3). The warning is written by ap_getword_conf, which doesn't know anything about server_rec structures. I've discovered this by trying to forward port this feature. However, I'd really like to see this warning to go into 2.1 and here written to the right log. What do you think about introducing a wrapper around ap_getword_conf, called ap_getword_conf_s (or similar, suggestions welcome ;-)? It would take server_rec *s as a third argument and could write the warning into the right place. Eek. Is it really worth emitting a warning on #'s not occurring at position 0 in the line? Seems like I'd prefer that this warning should be done at a higher level than ap_getword_conf (at a level which has access to server_rec). I'd prefer not to clutter up the interface just for *that*. -- justin
Re: mod_ssl to-do items
--On Thursday, March 6, 2003 12:42 PM -0500 Geoff Thorpe [EMAIL PROTECTED] wrote: linking apache. I'm wondering if the above problem is a consequence of us explicitly setting linker syntax and not letting autotools do their job properly? Anyway, the patch is there if someone wants to see if it helps with this issue as well. I think the issue is that mod_ssl as a DSO has to have a special set of linker flags just for *it* rather than relying on the original set of libraries (i.e. pull in OpenSSL). The proper solution to this would be to allow a module to explicitly have its own compiler, linker, etc. flags. (mod_deflate as a DSO could benefit if only it linked against libz.) It's a slightly more generic problem than just mod_ssl. * session cache store should be pluggable I'd like to speak with the person who's behind this, as I'm waiting for (Pardon me while I go off on a tangent...) Note that there really isn't a single person who is responsible for mod_ssl. The only person who may claim that is Ralf and he hasn't been involved for years. All of us on this list are implicitly responsible. Some people are more involved than others though - Madhu and DougM have been beneficial to keeping it running though (among others that I have forgotten right now - sorry!) - but the point of adding mod_ssl to our tree was so that it could be group-maintained rather than a specific individual. So, I wouldn't go look for a specific person to talk to. Whomever that person would be should be reading this list. Just start having a conversation about what you'd like to see happen on this list and people will magically start to chime in. And, keep submitting patches about what you'd like to see fixed - it's the surefire way of getting our attention. (And, simply repost if you don't hear anything in a week...) * the shmcb code should just align its memory segment rather than jumping through all the safe memcpy and memset hoops I wrote shmcb and I don't think the person who wrote this quite understands why this jumping through hoops is done. Trying to align all the relevant data will cost more than just a few wasted bytes of storage, and I respectfully suggest that the safe accessors (which aren't speed-critical) would be easier to maintain. Again, I'm available to bash these ideas out if anyone's interested. It's probably under the idea that we'd save a few cycles and make the code more understandable if we relied upon alignment. In fact, I believe the second argument is the more compelling one. I find the safe calls a tremendous difficulty in understanding the shmcb code (which, AIUI, is broken right now). -- justin
Re: stuck with prefork if you have out-of-tree APR
--On Thursday, March 6, 2003 4:14 PM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: server/mpm/config.m4 has this check with a hard-coded path to APR: APR_CHECK_APR_DEFINE(APR_HAS_THREADS, srclib/apr) This fails if APR is anywhere else and config doesn't think APR has thread support. Is this macro busted and should be replaced with something that does a test compile using the current $INCLUDES in $CPPFLAGS? Yes. $INCLUDES should contain the APR includes by that time. -- justin
