Re: protocol/4716: Server send invalid response if chunked transfer has chunk larger than 4095 bytes. (fwd)
The following reply was made to PR protocol/4716; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: protocol/4716: Server send invalid response if chunked transfer has chunk larger than 4095 bytes. (fwd) Date: Thu, 12 Aug 1999 19:01:16 -0700 (PDT) -- Forwarded message -- Date: Thu, 12 Aug 1999 21:57:33 -0400 (EDT) From: Dave Jones [EMAIL PROTECTED] Subject: Re: protocol/4716: Server send invalid response if chunked transfer has chunk larger than 4095 bytes. To: [EMAIL PROTECTED] X-VMS-To: IN%[EMAIL PROTECTED] X-VMS-Cc: JONESD I just used modules/test/mod_rndchunk to test things again... it calls into ab_bwrite with lots of different sizes, and I cranked it way up past the 4096 limit... Th ap_config.h file I was using (inherited) set DEFAULT_BUFSIZE to 8192, so the end_chunk code was seeing buffers larger than 4096. Letting DEFAULT_BUFSIZE be 4096 lets all the chunk headers fit in 5 bytes. There is a nice comment in buff.c explaining CHUNK_HEADER_SIZE's dependance on DEFAULT_BUFSIZE, shouldn't there be an assertion to catch this misconfiguration at compile-time? David L. Jones | Phone:(614) 292-6929 Ohio State University| Internet: 140 W. 19th St. Rm. 231a | [EMAIL PROTECTED] Columbus, OH 43210 | [EMAIL PROTECTED]
RE: protocol/3993: Incomplete Pages Loading Randomly (fwd)
The following reply was made to PR protocol/3993; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: RE: protocol/3993: Incomplete Pages Loading Randomly (fwd) Date: Sat, 1 May 1999 10:15:52 -0700 (PDT) -- Forwarded message -- From: Darron Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: protocol/3993: Incomplete Pages Loading Randomly Date: Wed, 21 Apr 1999 12:38:53 +0100 It seems to indeed be a problem with incomplete packets. In particular something called TCP slow start. This is where when an initial connection is made between client and server the number of packets sent at once is slowly built up. This is where I ran into problems with my little Solaris server on the very large BBC WAN (Probably the largest single Network in the world with up to 50,000 devices connected to it). The default network set up for a Solaris 2.6 box is for a small LAN of about 10 units. Basically I had to do a little ndd tweaking of the device drivers in particular ndd -set /dev/tcp tcp_slow_start_initial 2 to increase the number of initial packets sent out as there is an packet ACK problem in windows 95/IE 3.01 with HTTP 1.0 protocols. It seems to have cured most of the problem. Darron
Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist
The following reply was made to PR os-linux/4268; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Karthik Prabhakar [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist Date: Sat, 1 May 1999 10:24:48 -0700 (PDT) On Thu, 22 Apr 1999, Karthik Prabhakar wrote: From the strace, it appears that the read() from the socket is taking a bit of time, as well as the flock(). the flock() is not abnormal -- it's used for interprocess synchronization. The read() is also probably not a problem... it's usually client latency. I'm not sure what's up... I'm actually going to have a chance to test this stuff out on a high end linux box under specweb this weekend I think. So I may be able to repeat it. Dean
Re: general/4160: Reading large amounts of data
The following reply was made to PR general/4160; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Peter Gordon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/4160: Reading large amounts of data Date: Sat, 1 May 1999 10:27:23 -0700 (PDT) On Thu, 22 Apr 1999, Peter Gordon wrote: This is where I am having a problem. From having a look at the source, it looks as if it goes out of its way to limit the size of the incoming information. It limits the incoming URI. You can't use URIs more than about 512 bytes without messing up older browsers, so there are various practical limits. Apache will handle up to about an 8k URI. When I POST less than 8K, the transfer works successfully. When I post more, I get the error message I don't understand how your POST is generating a huge URI. This is outside Apache's control. POST should generate a request body, and not change the URI. Or perhaps your script is generating a massive URI in the action= field. If so, then I suggest you move some of the data in that URI into hidden fields. Dean
Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers
The following reply was made to PR general/4224; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: John Saario [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/4224: I get an inconsistend error, incomplete header sent error, but it works fine with ALL other browsers Date: Sat, 1 May 1999 10:31:48 -0700 (PDT) Oh, you're running apache in inetd mode? That mode probably has bugs... in fact I'm about to remove it from the server. Try running apache in standalone mode please. Dean On Wed, 28 Apr 1999, John Saario wrote: Dean I tried that by upgrading to apache 1.3.6 ... and putting in a no-keep alive for IE 5.0 but same result. KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 BrowserMatch Mozilla/2 nokeepalive BrowserMatch MSIE 4\.0b2; nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch MSIE 5\.0; nokeepalive downgrade-1.0 force-response-1.0 As long as I don't need to change any auth settings from default this should work? Worse, and I have not yet reported this yet, but after 3 days apache 1.3.6 causes inetd to lock up on FreeBSD .. I tried this both on FreeBSD 3.0 and 2.2.6. If I try to login via telnet inetd bails with some pointer too low error. Restarting apache from the console doesn't fix it. Hup of inetd doesn't fix it, but killing inetd and restarting it does fix it. Of course server reboot will fix it as well. But anyway it doesn't show up on my servers for about 3 days that boom, locked out. Pretty serious for me since I am in Singapore and 5 of my servers are in the USA. Anyway, hope you can forward that on. Still getting the incomplete header information for all the IE 5.0 clients. I switched back to apache_1.1.1 because of the inetd problem. I didn't notice 1.3.6 seems to be as fast as older versions of apache and that is why I liked it and upgraded ... I'll be watching for the next release to see if it's fixed since I know most my servers are running very old ( but faster ) versions.
Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd)
The following reply was made to PR os-linux/3343; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. (fwd) Date: Sat, 1 May 1999 10:41:56 -0700 (PDT) -- Forwarded message -- Date: Wed, 17 Mar 1999 12:13:59 -0600 From: Darrin Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: os-linux/3343: Server dies after 1-20 hours of usage. As per your request, the following is the netstat -nt command issued after the server hung... [EMAIL PROTECTED] /root]# netstat -nt Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 368 0 206.65.73.212:80169.207.68.4:6337 CLOSE_WAIT tcp 368 0 206.65.73.212:80169.207.68.4:6326 CLOSE_WAIT tcp 391 0 206.65.73.205:80142.103.168.111:3458 CLOSE_WAIT tcp 416 0 206.65.73.205:80216.199.5.169:46679 ESTABLISHED tcp 343 0 206.65.73.205:80205.188.154.138:48871 CLOSE_WAIT tcp 311 0 206.65.73.205:80152.2.179.50:2072 CLOSE tcp 391 0 206.65.73.205:80142.103.168.111:3459 CLOSE_WAIT tcp 311 0 206.65.73.205:80152.2.179.50:2073 CLOSE tcp 289 0 206.65.73.205:8012.4.54.254:2060 CLOSE tcp 322 0 206.65.73.205:80139.78.213.97:3066 CLOSE_WAIT tcp 311 0 206.65.73.205:80152.2.179.50:2074 CLOSE tcp 416 0 206.65.73.205:80216.199.5.148:46680 ESTABLISHED tcp 1715 0 206.65.73.205:80142.103.168.111:3460 CLOSE_WAIT tcp 140 0 206.65.73.205:80209.67.244.80:2155 ESTABLISHED tcp 289 0 206.65.73.205:8012.4.54.254:2061 CLOSE tcp 270 0 206.65.73.205:80139.78.213.97:3094 CLOSE_WAIT tcp 289 0 206.65.73.205:8012.4.54.254:2062 CLOSE tcp 320 0 206.65.73.205:80128.171.242.1:23279 CLOSE_WAIT tcp 343 0 206.65.73.205:80205.188.154.138:60184 CLOSE_WAIT tcp 391 0 206.65.73.205:80142.103.168.111:3461 CLOSE_WAIT tcp 264 0 206.65.73.212:80206.101.224.99:34452 CLOSE_WAIT tcp 348 0 206.65.73.205:8012.4.54.254:2073 ESTABLISHED tcp0 0 206.65.73.205:80142.103.168.111:3462 ESTABLISHED tcp 385 0 206.65.73.205:80142.103.168.111:3463 CLOSE_WAIT tcp 264 0 206.65.73.212:80206.101.224.99:34554 CLOSE_WAIT tcp0124 206.65.73.205:23206.65.72.12:3243 ESTABLISHED tcp 241 0 206.65.73.205:80142.103.168.111:3471 ESTABLISHED tcp 342 0 206.65.73.205:80205.188.154.138:6924 ESTABLISHED Also, please be aware of the fact that the problem seemed to have changed when we upgraded to the Redhat 5.2rpm version of Apache.. now, instead of crashing every 20-24 hours, it is not expiring all requests, and eventually will lock up all available processes... I'll try and include a copy or you can view it yourself at http://www.v6fbody.com/server-status Login:apache Password:group Thank you. Darrin Martin ---snip- Comment-Added-By: dgaudet Comment-Added-When: Tue Mar 16 08:34:26 PST 1999 Comment-Added: When the problem happens, do a netstat -nt -- that should show to where the ESTABLISHED port 80 connections are ... I suspect something is just holding connections open. If that doesn't help, use strace on a few of the children to see what they're doing: strace -p pid_of_child Dean
Re: os-linux/4268: Performance drops off after high specweb loads on highperformance-conf-dist (fwd)
The following reply was made to PR os-linux/4268; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Subject: Re: os-linux/4268: Performance drops off after high specweb loads
on highperformance-conf-dist (fwd)
Date: Wed, 21 Apr 1999 19:31:51 -0700 (PDT)
-- Forwarded message --
Date: Thu, 22 Apr 1999 02:45:13 +
From: Karthik Prabhakar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: apache-bugdb@apache.org, [EMAIL PROTECTED]
Subject: Re: os-linux/4268: Performance drops off after high specweb loads on
highperformance-conf-dist
[EMAIL PROTECTED] wrote:
Synopsis: Performance drops off after high specweb loads on
highperformance-conf-dist
State-Changed-From-To: open-feedback
State-Changed-By: dgaudet
State-Changed-When: Tue Apr 20 09:52:08 PDT 1999
State-Changed-Why:
Can you strace the children and see what they're doing?
Specifically use strace -r -T so that we can see where
time is being spent.
Do the children grow in size?
Does this happen on a redhat 5.2 system? (I don't like getting
reports from beta versions of anything... especially something
like glibc 2.1)
Dean
I finally got a hold of a redhat 5.2 / glibc2.1 system running a
stock 2.2.5 kernel, and replicated the problem. Attached is a
tcpdump, as well as a strace of the httpd processes.
From the strace, it appears that the read() from the socket is
taking a bit of time, as well as the flock(). I might
conclude that this could be a linux problem, except that killing
restarting the apache process fixes the problem. Besides, the
problem does not occur with other web server's I've tried.
Again, I've only managed to make this happen on the
highperformance-conf.dist config file, and not on the default
apache httpd.conf file.
Do you think I need to bring this up on the linux-kernel list?
thanks!
karthik
tcpdump:18:17:06.539084 15.54.164.205.2284 15.5.2.41.80: S
570626839:570626839(0) win 8192 mss 1460 (DF) (ttl 126, id 5983)
18:17:06.539135 15.5.2.41.80 15.54.164.205.2284: S 2713308169:2713308169(0)
ack 570626840 win 0 mss 1460 (DF) (ttl 64, id
25657)
18:17:06.539979 15.54.164.205.2284 15.5.2.41.80: . ack 1 win 8760 (DF) (ttl
126, id 6239)
18:17:09.544373 15.54.164.205.2284 15.5.2.41.80: . 1:2(1) ack 1 win 8760
(DF) (ttl 126, id 6495)
18:17:09.544414 15.5.2.41.80 15.54.164.205.2284: . ack 1 win 32120 (DF) (ttl
64, id 25658)
18:17:09.545829 15.54.164.205.2284 15.5.2.41.80: P 1:267(266) ack 1 win 8760
(DF) (ttl 126, id 6751)
18:17:09.545871 15.5.2.41.80 15.54.164.205.2284: . ack 267 win 31854 (DF)
(ttl 64, id 25659)
18:17:09.547965 15.5.2.41.80 15.54.164.205.2284: . 1:1461(1460) ack 267 win
32120 (DF) (ttl 64, id 25660)
18:17:09.744598 15.54.164.205.2284 15.5.2.41.80: . ack 1461 win 8760 (DF)
(ttl 126, id 7007)
18:17:09.744643 15.5.2.41.80 15.54.164.205.2284: . 1461:2921(1460) ack 267
win 32120 (DF) (ttl 64, id 25661)
18:17:09.744653 15.5.2.41.80 15.54.164.205.2284: . 2921:4381(1460) ack 267
win 32120 (DF) (ttl 64, id 25662)
[.. uninteresting stuff deleted ..]
18:17:10.620546 15.5.2.41.80 15.54.164.205.2284: . 128481:129941(1460) ack
267 win 32120 (DF) (ttl 64, id 25748)
18:17:10.625721 15.54.164.205.2284 15.5.2.41.80: . ack 128481 win 1460 (DF)
(ttl 126, id 21855)
18:17:10.645192 15.54.164.205.2284 15.5.2.41.80: . ack 129941 win 4380 (DF)
(ttl 126, id 22111)
18:17:10.645237 15.5.2.41.80 15.54.164.205.2284: P 129941:131401(1460) ack
267 win 32120 (DF) (ttl 64, id 25749)
18:17:10.645246 15.5.2.41.80 15.54.164.205.2284: . 131401:132861(1460) ack
267 win 32120 (DF) (ttl 64, id 25750)
18:17:10.645256 15.5.2.41.80 15.54.164.205.2284: P 132861:134287(1426) ack
267 win 32120 (DF) (ttl 64, id 25751)
18:17:10.650327 15.54.164.205.2284 15.5.2.41.80: . ack 132861 win 1460 (DF)
(ttl 126, id 22367)
18:17:10.669796 15.54.164.205.2284 15.5.2.41.80: . ack 134287 win 4414 (DF)
(ttl 126, id 22623)
18:17:10.693746 15.54.164.205.2284 15.5.2.41.80: . ack 134287 win 8760 (DF)
(ttl 126, id 22879)
18:17:26.757288 15.5.2.41.80 15.54.164.205.2284: F 134287:134287(0) ack 267
win 32120 (DF) (ttl 64, id 25752)
18:17:26.758424 15.54.164.205.2284 15.5.2.41.80: . ack 134288 win 8760 (DF)
(ttl 126, id 23647)
strace:
[pid 376] 0.00 flock(18, LOCK_EX unfinished ...
[pid 375] 0.000203 flock(18, LOCK_EX unfinished ...
[pid 374] 0.71 flock(18, LOCK_EX unfinished ...
[pid 373] 0.68 flock(18, LOCK_EX unfinished ...
[pid 296] 0.68 flock(18, LOCK_EX unfinished ...
[pid 282] 0.68 flock(18, LOCK_EX unfinished ...
[pid 281] 0.68 flock(18, LOCK_EX unfinished ...
[pid 280] 0.68 flock(18, LOCK_EX unfinished ...
[pid 279] 0.68 flock(18, LOCK_EX unfinished ...
[pid 278] 0.90 accept(15, unfinished ...
[pid 277] 0.000105 select(0, NULL, NULL, NULL, {0
Re: mod_cgi/3751: CGI scripts arent killed when they are in deadlock (fwd)
The following reply was made to PR mod_cgi/3751; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_cgi/3751: CGI scripts arent killed when they are in deadlock (fwd) Date: Thu, 22 Apr 1999 02:41:41 -0700 (PDT) -- Forwarded message -- Date: Thu, 22 Apr 1999 10:22:11 +0200 From: Viktor Bodrogi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: mod_cgi/3751: CGI scripts arent killed when they are in deadlock Hi! Thanks for answering my question, but it's already eliminated by using fcgi. So I even don't remember the situation, but I'm sure it was a problem for me, having some deadlocked cgi's runing for hours until I kill them. Probably they did write anything, but in this case they should killed when the client disconnects, shouldn't they? Anyway, mod_fcgi is a great solution, we have a very overloaded server, with normal cgi the processor load was about 50 sometimes, now it's always under 5. According to my benchmarks the server answers about 20-30 times faster now (without load). Thanks anyway! [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: CGI scripts arent killed when they are in deadlock State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Tue Apr 20 20:53:47 PDT 1999 State-Changed-Why: I'm not sure what you mean by deadlocked ... ? If a timeout occurs the connection to the CGI is closed. The timeout won't happen if the CGI writes anything, unless the client never reads it. Do you have a small example we can reproduce the problem with? If I test CGIs that just sleep forever the timeout works fine. Dean
Re: general/3869: Server doesn't close connections after timeout period
Oh btw, here's a patch you might want to try. It's just a wild guess
though.
Dean
Index: main/http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.430
diff -u -r1.430 http_main.c
--- http_main.c 1999/04/20 19:15:39 1.430
+++ http_main.c 1999/04/21 00:07:43
@@ -3601,6 +3601,7 @@
#endif
#endif
signal(SIGALRM, alrm_handler);
+signal(SIGUSR2, alrm_handler);
#ifdef OS2
/* Stop Ctrl-C/Ctrl-Break signals going to child processes */
@@ -4105,7 +4106,7 @@
else if (ps-last_rtime + ss-timeout_len now) {
/* no progress, and the timeout length has been exceeded */
ss-timeout_len = 0;
- kill(ps-pid, SIGALRM);
+ kill(ps-pid, SIGUSR2);
}
}
#endif
Re: config/3906: Servers hang on either Keepalive or on Read (if keepalive is turned off)
BTW, here's a patch you may want to try. It's just a wild guess though...
Dean
Index: main/http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.430
diff -u -r1.430 http_main.c
--- http_main.c 1999/04/20 19:15:39 1.430
+++ http_main.c 1999/04/21 00:07:43
@@ -3601,6 +3601,7 @@
#endif
#endif
signal(SIGALRM, alrm_handler);
+signal(SIGUSR2, alrm_handler);
#ifdef OS2
/* Stop Ctrl-C/Ctrl-Break signals going to child processes */
@@ -4105,7 +4106,7 @@
else if (ps-last_rtime + ss-timeout_len now) {
/* no progress, and the timeout length has been exceeded */
ss-timeout_len = 0;
- kill(ps-pid, SIGALRM);
+ kill(ps-pid, SIGUSR2);
}
}
#endif
Re: mod_dir/3596: mod_dir doesn't handle requests which must be processed internally by mod_proxy
The following reply was made to PR mod_dir/3596; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Radu Greab [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_dir/3596: mod_dir doesn't handle requests which must be processed internally by mod_proxy Date: Wed, 21 Apr 1999 10:20:45 -0700 (PDT) On Wed, 21 Apr 1999, Radu Greab wrote: [EMAIL PROTECTED] writes: No, you have to fill in r-finfo if you're implementing something which pretends to be the filesystem... that's just how it is. You don't have to fill in much, just set the mode and mtime or something like that. I know, it's not well documented, but what of the api is? Do you suggest that just because I need to transparrently provide dynamic content from another server I have to create bogus files on the filesystem? No I wasn't saying that. I'm saying if a content handler provides file-like objects it needs to fill in r-finfo.st_mode and r-finfo.st_mtime. It doesn't need to create files to do that. To solve my problem I have a few possibilities: 1) use my patch against mod_dir to make it proxy aware. The advantage is that I can use a minimum configuration in httpd.conf (one line) and it doesn't require _bogus_ files and the task can be solved with two modules compiled in: mod_dir and mod_proxy. The bug isn't in mod_dir, it's in mod_proxy. mod_dir follows the API. Dean
Re: mod_log-any/3713: Piped Error Logs spawn extra process(es) (fwd)
The following reply was made to PR other/3713; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_log-any/3713: Piped Error Logs spawn extra process(es) (fwd) Date: Wed, 21 Apr 1999 10:32:46 -0700 (PDT) -- Forwarded message -- From: [EMAIL PROTECTED] Subject: Re: mod_log-any/3713: Piped Error Logs spawn extra process(es) To: [EMAIL PROTECTED] Date: Wed, 21 Apr 1999 11:39:43 -0400 (EDT) Cc: apache-bugdb@apache.org Dean, I was actually using a hacked version of rotatelogs--I just sent the simple item as an example. The rotatelogs.c file in the distribution should be updated to handle this, or if exec would work for it as well, examples of it with the Log directive should be updated to show the exec. Because we didn't understand this, we chose not to use piped logging in our current release. With this knowledge, we may revisit this issue at a later time, -- thanks very much for the info, sam
Re: mod_log-any/3802: would like to add an option,%R, to expand directory requests to include the filename within CLF (fwd)
The following reply was made to PR mod_log-any/3802; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_log-any/3802: would like to add an option,%R, to expand directory requests to include the filename within CLF (fwd) Date: Wed, 21 Apr 1999 10:33:00 -0700 (PDT) -- Forwarded message -- From: [EMAIL PROTECTED] Subject: Re: mod_log-any/3802: would like to add an option,%R, to expand directory requests to include the filename within CLF To: [EMAIL PROTECTED] Date: Wed, 21 Apr 1999 11:34:19 -0400 (EDT) Cc: apache-bugdb@apache.org Dean, We present reports to our customers and we allow our customers to get their raw log files. Since most tools understand extended CLF, we provide that (or something that looks like it) to our customers. If I understand you correctly, you are suggesting that we add a new field (at the end of the log) and strip it off before shipping it to the customer. We could use the new field in combination with the URL presented via %r to construct the correct file name, path/info, and query string in all cases. Of course, the above is possible. Wouldn't it be easier for everyone concerned to implement a different change request, PR2772. Allow us to put the %r together by having separate options for method, uri-w-query, and protocol. I implemented PR2772 using %V for uri-w-query to my dismay when I found out that Apache 1.3.6 used %V for something else. Oh well. There are many users of Apache, it is simpler to change LogFormat entries than write code--clearly, it is not a hugh impact for hundreds of us to write a little code, but I think it is better to localize the little code to 1 place--in this case, Apache. -- one man's opinion, sam
Re: os-linux/4251: Clients (incorrectly?) receive TCP reset packets.
The following reply was made to PR os-linux/4251; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Don Rude [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-linux/4251: Clients (incorrectly?) receive TCP reset packets. Date: Tue, 20 Apr 1999 11:24:29 -0700 (PDT) Well Apache does nothing to put an RST on a packet. That's a TCP layer decision outside the control of the application. It's a kernel bug if it is happenning. I know it's not happenning on my 2.0.36 servers. Get a tcpdump of the thing and send a report to linux-kernel... if they say it's apache's fault then report it back to us, thanks. Dean On Tue, 20 Apr 1999, Don Rude wrote: [EMAIL PROTECTED] wrote: If this is the case it's a kernel bug. Post to linux-kernel describing it... better yet, try 2.2.6 now that it's out. As mentioned I have tried at least one other kernel. Now, I have also upgraded both boxes to 2.2.6 and I get the same packet sequence. -- Don RudeLead Hacker (V)301-208-1658 (F)301-208-9731 Build your world. http://STEEM.com
Re: os-linux/4151: After sometime runing well (hours, days) httpd's performance goes down. (fwd)
The following reply was made to PR os-linux/4151; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: os-linux/4151: After sometime runing well (hours, days) httpd's performance goes down. (fwd) Date: Tue, 20 Apr 1999 13:26:32 -0700 (PDT) -- Forwarded message -- From: Chung Ming [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: os-linux/4151: After sometime runing well (hours, days) httpd's performance goes down. Date: Tue, 20 Apr 1999 16:08:03 -0700 thanks! I have discover the problem was SYN attacks over .36 kernel, now it works fine at 2.2.5 -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: apache-bugdb@apache.org apache-bugdb@apache.org; [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, April 20, 1999 12:20 PM Subject: Re: os-linux/4151: After sometime runing well (hours, days) httpd's performance goes down. [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: After sometime runing well (hours, days) httpd's performance goes down. State-Changed-From-To: open-feedback State-Changed-By: dgaudet State-Changed-When: Tue Apr 20 12:20:08 PDT 1999 State-Changed-Why: please try linux kernel version 2.2.6 or 2.0.36 thanks Dean
re: general/3872: util_script.c doubles up Set-Cookie headers from r-err_headers_out
The following reply was made to PR general/3872; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: Jeff Lewis [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: re: general/3872: util_script.c doubles up Set-Cookie headers from
r-err_headers_out
Date: Wed, 10 Mar 1999 10:05:48 -0800 (PST)
Commenting out the ap_table_do line would pose troubles if there were two
Set-Cookie headers already in err_headers_out... I'm pretty sure the patch
below is the right way to fix it. Can you test to make sure it works for
you?
Thanks
Dean
Index: main/util_script.c
===
RCS file: /home/cvs/apache-1.3/src/main/util_script.c,v
retrieving revision 1.138
diff -u -r1.138 util_script.c
--- util_script.c 1999/02/05 00:37:48 1.138
+++ util_script.c 1999/03/10 18:04:53
@@ -496,6 +496,8 @@
ap_overlap_tables(r-err_headers_out, merge,
AP_OVERLAP_TABLES_MERGE);
if (!ap_is_empty_table(cookie_table)) {
+ /* the cookies have already been copied to the cookie_table */
+ ap_table_unset(r-err_headers_out, Set-Cookie);
r-err_headers_out = ap_overlay_tables(r-pool,
r-err_headers_out, cookie_table);
}
Re: general/3039: MMapFile doesn't do what it should (file edits are read by server)
The following reply was made to PR general/3039; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Daniel C. Stevenson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/3039: MMapFile doesn't do what it should (file edits are read by server) Date: Tue, 22 Sep 1998 18:32:01 -0700 (PDT) On Mon, 21 Sep 1998, Daniel C. Stevenson wrote: From www.apache.org/docs/mod/mod_mmap_static: ... To reiterate that point: if the files are modified in place without restarting the server you may end up serving requests that are completely bogus. ... Does bogus include actually recognizing/displaying the modified files without restarting the server (which is the behavior I saw)? bogus means anything, it means anything could happen. As in, it could play Merry had a Little Lamb for you :) You happen to have gotten lucky and the changes did something that you think is right. It isn't though. The documentation explicitly says that you have to restart the server. It also explicitly says not to modify the files in place. The whole thing is experimental and regular sites don't need it at all. Dean
Re: general/3039: MMapFile doesn't do what it should (file edits are read by server)
The following reply was made to PR general/3039; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Dan Stevenson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/3039: MMapFile doesn't do what it should (file edits are read by server) Date: Mon, 21 Sep 1998 15:51:15 -0700 (PDT) From www.apache.org/docs/mod/mod_mmap_static: ... To reiterate that point: if the files are modified in place without restarting the server you may end up serving requests that are completely bogus. ... Which is exactly the behaviour you're describing. Dean
Re: general/2850: Server restart causes long lost child came home!
The following reply was made to PR general/2850; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: general/2850: Server restart causes long lost child came home! Date: Fri, 11 Sep 1998 08:14:22 -0700 (PDT) Damn I thought I fixed this bug... thanks, it should be easy to reproduce now. Dean On Fri, 11 Sep 1998 [EMAIL PROTECTED] wrote: The PIDs for the long lost children refer to the programs handling piped CustomLogs, not to forked httpd processed. Thus the proplem is solved. Hans Werner Strube [EMAIL PROTECTED] Drittes Physikalisches Institut, Univ. Goettingen Buergerstr. 42-44, D-37073 Goettingen, Germany
Re: os-solaris/2834: Seeing lots of[Wed Aug 12 02:41:56 1998] access to /index_layout.html failed for 172.16.20.2, reason: stat: Stale NFS file handle (errno = 151) in error log
The following reply was made to PR os-solaris/2834; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jay Soffian [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/2834: Seeing lots of[Wed Aug 12 02:41:56 1998] access to /index_layout.html failed for 172.16.20.2, reason: stat: Stale NFS file handle (errno = 151) in error log Date: Wed, 19 Aug 1998 11:16:50 -0700 (PDT) On 12 Aug 1998, Jay Soffian wrote: errno = 0; rv = stat(path, r-finfo); + if (rv 0 errno == ESTALE) /* workaround for Stale NFS Filehandle problem */ + rv = stat(path, r-finfo); /* with Solaris's rnode cache */ But what do you do about this problem when it occurs in a 3rd party library that you don't have source for? Such as libc? Sorry this is a kernel bug, the hack above fixes it for only one single case. I don't see the point in fixing it for the one case when there are potentially dozens of others that could be broken. You should complain to your solaris rep. I'd be more sympathetic if EINTR were one of the posix errors for stat() -- at least then there would be precedence for having to retry a stat. But it isn't... (and I don't see ESTALE documented on the solaris man page either). bleh. I'll leave the PR open though, maybe someone else feels differently. Dean
Re: general/2850: Server restart causes long lost child came home!
The following reply was made to PR general/2850; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Hans Werner Strube [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2850: Server restart causes long lost child came home! Date: Wed, 19 Aug 1998 11:25:53 -0700 (PDT) Do you use any piped logs? Before doing a restart can you capture /usr/ucb/ps -auxwww output, then do the restart... look at the log to find the pids of the long lost children, and find out what they were from the ps output? Thanks Dean
Re: os-solaris/2834: Seeing lots of[Wed Aug 12 02:41:56 1998] access to /index_layout.html failed for 172.16.20.2, reason: stat: Stale NFS file handle (errno = 151) in error log
The following reply was made to PR os-solaris/2834; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jay Soffian [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/2834: Seeing lots of[Wed Aug 12 02:41:56 1998] access to /index_layout.html failed for 172.16.20.2, reason: stat: Stale NFS file handle (errno = 151) in error log Date: Wed, 19 Aug 1998 11:36:18 -0700 (PDT) On 19 Aug 1998, Jay Soffian wrote: Yeah, you and me both. You can't imagine how long this took to track down. Sun should be shot for passing this problem up to the application level. Actually sun should just be shot for NFS. ;) Dean
Re: general/2819: errors detected when parsing the headers aren't sent to the client
The following reply was made to PR general/2819; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Tony Finch [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2819: errors detected when parsing the headers aren't sent to the client Date: Wed, 12 Aug 1998 10:40:05 -0700 (PDT) There's a patch either in 1.3.1 or 1.3.2-dev to take care of this. Can you try it against the current dev copy, you can find it at ftp://dev.apache.org/httpd/from-cvs/. Thanks Dean
Re: general/2487: ap_strcmpmatch fails on case-blind file systems (Severe error)
The following reply was made to PR general/2487; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jens Stavnstrup [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2487: ap_strcmpmatch fails on case-blind file systems (Severe error) Date: Mon, 6 Jul 1998 20:31:39 -0700 (PDT) Location is for protecting URLs, not the filesystem. Directory is for protecting the filesystem... and for at least non-wildcard Directory sections, there shouldn't be any problem. (wildcard stuff is fixed in 1.3.1-dev). See the documentation, this distinction is spelled out. For example: Note that URLs do not have to line up with the filesystem at all, it should be emphasized that Location operates completely outside the filesystem. Dean
Re: general/2516: Compilation fails: wait() wants union wait status and some redefinition warnings
The following reply was made to PR general/2516; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: =?iso-2022-jp?B?GyRCJEokKyQ4GyhC?= [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: general/2516: Compilation fails: wait() wants union wait status and some redefinition warnings Date: Mon, 6 Jul 1998 20:47:13 -0700 (PDT) On 28 Jun 1998, [iso-2022-jp] なかじ wrote: My easy patch I submitted last night (in Japan) is not good. I think Mr. Makoto Matsushita([EMAIL PROTECTED])'s one is better. It is in ftp://ftp.ics.es.osaka-u.ac.jp/NEWS4aid/application-patches/apache-1.3.0.patch That URL didn't work for me. In any event we've already had to fix a few things like this in 1.3.1-dev. If one of you could pick up a snapshot at ftp://dev.apache.org/httpd/from-cvs/ and resubmit a patch that would be great. Thanks Dean
Re: os-irix/2558: compilation failure of http_mail.c in copy_listeners
The following reply was made to PR os-irix/2558; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Judith Bush [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-irix/2558: compilation failure of http_mail.c in copy_listeners Date: Mon, 6 Jul 1998 21:20:25 -0700 (PDT) On 6 Jul 1998, Judith Bush wrote: cc -c -I../os/unix -I../include -DIRIX -n32 -DSTATUS -DUSE_HSREGEX http_main.c http_main.c, line 2978: error(1010): # not expected here ap_assert(old_listeners == NULL); ^ Looks like your c preprocessor is not ANSI standard. If that's the IRIX compiler that you have to buy, then bitch to SGI. If it came with the system there's a good chance it only pretends to be ANSI... in that case use gcc instead. Dean
Re: general/2441: entries in log files appear widely out of order, sometimes not at all
The following reply was made to PR general/2441; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: general/2441: entries in log files appear widely out of order, sometimes not at all Date: Wed, 24 Jun 1998 02:44:05 -0700 (PDT) -- Forwarded message -- Date: 24 Jun 1998 08:21:02 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at twinlark.arctic.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Sorry, I couldn't find any host by that name. (#4.1.2) I'm not going to try again; this message has been in the queue too long. --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 25381 invoked by uid 500); 17 Jun 1998 07:19:46 - Date: Wed, 17 Jun 1998 00:19:46 -0700 (PDT) From: Dean Gaudet [EMAIL PROTECTED] To: Jay Richmond [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: general/2441: entries in log files appear widely out of order, sometimes not at all In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If I had to guess I'd say the freebsd port includes -DBUFFERED_LOGS. If so, they should be taken out and shot. twice. I don't have access to freebsd, so someone else will have to check. Dean
RE: general/2477: FollowSymLinks directive does not work in Virtual hosts (fwd)
The following reply was made to PR general/2477; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: RE: general/2477: FollowSymLinks directive does not work in Virtual hosts (fwd) Date: Mon, 22 Jun 1998 13:47:46 -0700 (PDT) Can someone else take over? I'm tired of trying to explain to people that their entire config is relevant. Dean -- Forwarded message -- From: Don O'Neil [EMAIL PROTECTED] To: Dean Gaudet [EMAIL PROTECTED] Subject: RE: general/2477: FollowSymLinks directive does not work in Virtual hosts Date: Mon, 22 Jun 1998 13:11:03 -0700 Dean, Here is my config, which is virtually identical to my 1.26 config with the exception that the paths are now hard... VirtualHost test.whtech.com ServerAdmin [EMAIL PROTECTED] DocumentRoot /usr/home/whtech/html ServerName test.whtech.com ErrorLog /usr/local/etc/apache/var/log/wht.error_log Directory /usr/home/whtech/html Options Indexes FollowSymLinks ExecCGI AllowOverride All order allow,deny allow from all /Directory Location /server-status SetHandler server-status Order deny,allow allow from all /Location /VirtualHost You can see that I have a Directory diretive, and that the option is set. Don -Original Message- From: Dean Gaudet [mailto:[EMAIL PROTECTED] Sent: Monday, June 22, 1998 12:04 AM To: Don O'Neil Cc: [EMAIL PROTECTED] Subject: RE: general/2477: FollowSymLinks directive does not work in Virtual hosts FollowSymLinks is a per-directory configuration setting. If you have any Directory containers and they have any Options settings which don't include FollowSymLinks then you've disabled symlinks. Dean
Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding
The following reply was made to PR os-solaris/2386; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jason Spears [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding Date: Wed, 17 Jun 1998 22:47:28 -0700 (PDT) If you look at /server-status what state does it show the children in? If a lot of the children appear to be stuck doing something, find the pid of one of them and then run truss against it... and send some output back so we can figure out where it's at. Oh yeah, another thing to try is to put LogLevel debug into your httpd.conf and see if any useful messages are printed in your error_log. Dean
Re: os-solaris/1190: server processes in keepalive state do not die after keepalive-timeout
The following reply was made to PR os-solaris/1190; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Eugene Crosser [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/1190: server processes in keepalive state do not die after keepalive-timeout Date: Wed, 17 Jun 1998 22:56:12 -0700 (PDT) Hmm, we don't appear to have all the betas online. Bleh. Here's a few suggestions. - If your ServerRoot is on NFS then you need to use the LockFile directive to move the lock file. - Try editing src/include/httpd.h, search for OPTIMIZE_TIMEOUTS, and comment out that line, so that it is not defined. Then recompile and see if that helps any. - You're not using any other options for compiling are you? Are you using gcc or solaris cc? Dean
Re: mod_auth-any/2459: Getting this message: [Wed Jun 17 11:37:04 1998] [notice] httpd: child pid 332 exit signal Segmentation Fault (11) when trying to access a DBM file
The following reply was made to PR mod_auth-any/2459; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: James Simpson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_auth-any/2459: Getting this message: [Wed Jun 17 11:37:04 1998] [notice] httpd: child pid 332 exit signal Segmentation Fault (11) when trying to access a DBM file Date: Wed, 17 Jun 1998 22:57:52 -0700 (PDT) Are you sure that 1.3.0 is being compiled with gdbm just like you say 1.2 is? What does the final link line look like when you type make? Dean
Re: os-solaris/1190: server processes in keepalive state do not die after keepalive-timeout
The following reply was made to PR os-solaris/1190; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: Eugene Crosser [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: os-solaris/1190: server processes in keepalive state do not die
after keepalive-timeout
Date: Wed, 17 Jun 1998 23:36:49 -0700 (PDT)
Maybe you could try this patch. It looks like there's a small race
condition with keepalive timeouts... but I don't understand why we don't
see it more frequently.
BTW, please set LogLevel debug in your httpd.conf and tell me if you get
any of those possible nested timer warnings.
Thanks
Dean
Index: main/http_main.c
===
RCS file: /export/home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.365
diff -u -r1.365 http_main.c
--- http_main.c1998/06/16 03:37:27 1.365
+++ http_main.c1998/06/18 06:18:53
@@ -975,6 +975,7 @@
}
else {/* abort the connection */
ap_bsetflag(current_conn-client, B_EOUT, 1);
+ ap_bclose(current_conn-client);
current_conn-aborted = 1;
}
}
@@ -1045,9 +1046,11 @@
alarm_expiry_time = time(NULL) + x;
}
#else
-if (x) {
- alarm_fn = fn;
+if (alarm_fn x fn != alarm_fn) {
+ ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_DEBUG, NULL,
+ ap_set_callback_and_alarm: possible nested timer!);
}
+alarm_fn = fn;
#ifndef OPTIMIZE_TIMEOUTS
old = alarm(x);
#else
Index: main/rfc1413.c
===
RCS file: /export/home/cvs/apache-1.3/src/main/rfc1413.c,v
retrieving revision 1.24
diff -u -r1.24 rfc1413.c
--- rfc1413.c 1998/05/18 21:56:11 1.24
+++ rfc1413.c 1998/06/18 06:18:53
@@ -229,9 +229,8 @@
if (get_rfc1413(sock, conn-local_addr, conn-remote_addr, user, srv)
= 0)
result = user;
-
- ap_set_callback_and_alarm(NULL, 0);
}
+ap_set_callback_and_alarm(NULL, 0);
ap_pclosesocket(conn-pool, sock);
conn-remote_logname = result;
Re: mod_auth-any/2459: Getting this message: [Wed Jun 17 11:37:04 1998] [notice] httpd: child pid 332 exit signal Segmentation Fault (11) when trying to access a DBM file
The following reply was made to PR mod_auth-any/2459; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Nakko Mizu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_auth-any/2459: Getting this message: [Wed Jun 17 11:37:04 1998] [notice] httpd: child pid 332 exit signal Segmentation Fault (11) when trying to access a DBM file Date: Thu, 18 Jun 1998 10:21:03 -0700 (PDT) In your post you mentioned gdbm, but it's not present on the link line below... I suspect you're getting dbm functions from libc, and that you may have compiled your 1.2.6 server with -lgdbm. If that's the case the seg faults are expected -- the two dbm libraries use different file formats. Try adding EXTRA_LIBS=-lgdbm to your Configuration file, reconfiguring and recompiling. Dean On Thu, 18 Jun 1998, Nakko Mizu wrote: Here is the run of the Configure bash-2.00# ./Configure Using config file: Configuration | Please note that the default httpd root directory has changed | from '/usr/local/etc/httpd/' to '/usr/local/apache/.' | You may add '-DHTTPD_ROOT=\/usr/local/etc/httpd\' to EXTRA_CFLAGS | in your Configuration file (and re-run Configure) or start | httpd with the option '-d /usr/local/etc/httpd' if you still | want to use the old root directory for your server. Creating Makefile + configured for Solaris 260 platform + setting C compiler to gcc + adding selected modules o status_module uses ConfigStart/End o rewrite_module uses ConfigStart/End enabling DBM support for mod_rewrite o dbm_auth_module uses ConfigStart/End + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in main Creating Makefile in ap Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in modules/standard Creating Makefile in modules/proxy And here is the run of Make bash-2.00# make === os/unix === os/unix === ap === ap === main === main === modules === modules/standard === modules/standard === modules/proxy === modules/proxy === modules gcc -c -I./os/unix -I./include -DSOLARIS2=260 -DSTATUS buildmark.c gcc -DSOLARIS2=260 -DSTATUS \ -o httpd buildmark.o modules.o modules/proxy/libproxy.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a -lsocket -lnsl Let me know. James Dean Gaudet wrote: Are you sure that 1.3.0 is being compiled with gdbm just like you say 1.2 is? What does the final link line look like when you type make? Dean
Re: os-solaris/1190: server processes in keepalive state do not die after keepalive-timeout
The following reply was made to PR os-solaris/1190; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Eugene Crosser [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/1190: server processes in keepalive state do not die after keepalive-timeout Date: Thu, 18 Jun 1998 10:37:24 -0700 (PDT) Yeah this sounds like the signal handler has been removed... which is why I sent the patch yesterday. You said you're using php, right? Is it the latest php? I believe php also plays with timeouts... do you connect to any sql databases with it? Dean On Thu, 18 Jun 1998, Eugene Crosser wrote: - Try editing src/include/httpd.h, search for OPTIMIZE_TIMEOUTS, and comment out that line, so that it is not defined. Then recompile and see if that helps any. I did this: no change. Now, I did a bit more investigation. First, sometimes the processes that stayed in Keepalive status several minutes (i.e. much longer than the KeepaliveTimeout) still finishes. I assume this may happen when the other end explicitely closes TCP connection. Next, if I choose a process that is staying keepalive for a long time and send it kill -ALRM it does not notice it and stays in the same status. If I send it kill -PIPE it gracefully resets and is ready to serve next requests. That's all for now. Please tell me what else I can do to help chasing the problem. Eugene
Re: os-solaris/1190: server processes in keepalive state do not die after keepalive-timeout
The following reply was made to PR os-solaris/1190; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Eugene Crosser [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/1190: server processes in keepalive state do not die after keepalive-timeout Date: Thu, 18 Jun 1998 10:36:10 -0700 (PDT) 1.3b5 used USE_PTHREAD_SERIALIZED_ACCEPT on solaris, and 1.3b6 uses USE_FCNTL_SERIALIZED_ACCEPT (as do all the 1.2.x and earlier versions). We switched back to fcntl because the pthread stuff was proving unreliable for a lot of folks... You could try adding EXTRA_CFLAGS=-DUSE_PTHREAD_SERIALIZED_ACCEPT and reconfiguring/compiling. But I really don't see how this will help. That's the only thing I can find... Dean On Thu, 18 Jun 1998, Eugene Crosser wrote: OK, I am now pretty certain that the fatal change happend between beta 5 and beta 6. Eugene
Re: mod_auth-any/2459: Getting this message: [Wed Jun 17 11:37:04 1998] [notice] httpd: child pid 332 exit signal Segmentation Fault (11) when trying to access a DBM file (fwd)
The following reply was made to PR mod_auth-any/2459; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_auth-any/2459: Getting this message: [Wed Jun 17 11:37:04 1998] [notice] httpd: child pid 332 exit signal Segmentation Fault (11) when trying to access a DBM file (fwd) Date: Thu, 18 Jun 1998 11:49:16 -0700 (PDT) -- Forwarded message -- Date: Thu, 18 Jun 1998 13:37:54 -0400 From: Nakko Mizu [EMAIL PROTECTED] To: Dean Gaudet [EMAIL PROTECTED] Subject: Re: mod_auth-any/2459: Getting this message: [Wed Jun 17 11:37:04 1998] [notice] httpd: child pid 332 exit signal Segmentation Fault (11) when trying to access a DBM file Ok, here is the new 'make' === modules/proxy === modules gcc -c -I./os/unix -I./include -DSOLARIS2=260 -DSTATUS modules.c gcc -c -I./os/unix -I./include -DSOLARIS2=260 -DSTATUS buildmark.c gcc -DSOLARIS2=260 -DSTATUS \ -o httpd buildmark.o modules.o modules/proxy/libproxy.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a -lgdbm -lsocket -lnsl bash-2.00# /test/apache_1.3.0/src/httpd -f /usr/local/apache/conf/httpd.conf And now it is getting: [Thu Jun 18 13:29:00 1998] [error] (2)No such file or directory: could not open dbm auth file: /u2/test.com/userdb/members *BUT* I can use the following command: bash-2.00# dbmmanage /u2/test.com/userdb/members view matrix7 matrix7:Mx92ZF35YpJCs Now the gdbm I got was from the www.sunsite.unc.edu in which I go the version for my Solaris 2.6 and x86 and copied it into the /usr/local/bin (it's already compiled). That is where I stand. James
Re: mod_log-any/2090: LogFormat directives are not inherited (fwd)
The following reply was made to PR mod_log-any/2090; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Subject: Re: mod_log-any/2090: LogFormat directives are not inherited
(fwd)
Date: Tue, 16 Jun 1998 23:51:55 -0700 (PDT)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to [EMAIL PROTECTED] for more info.
--23269446CC34D6EBA8014F75
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: [EMAIL PROTECTED]
-- Forwarded message --
Date: Thu, 11 Jun 1998 10:00:31 +0100
From: Christof Damian [EMAIL PROTECTED]
Organization: mediaconsult ltd.
To: Dean Gaudet [EMAIL PROTECTED]
Cc: Johnie Ingram [EMAIL PROTECTED]
Subject: Re: mod_log-any/2090: LogFormat directives are not inherited
Dean Gaudet wrote:
Christof -- a small bug in your patch. I think you need to delay the
parsing of log formats until the open_multi_logs point like I suggested,
rather than in the merging point... because the main server is never
merged (there's nothing to merge into it). Can I trouble you to fix that?
:)
ups - I thought I checked that.
Attached is a patch against 1.60 (cvs tree) and one against 1.59 (1.3.0)
I don't know which one you prefer.
damian
--
Christof Damian
Technical Director
http://www.mediaconsult.com/ ( btw: mediaconsult is hiring )
--23269446CC34D6EBA8014F75
Content-Type: TEXT/PLAIN; CHARSET=us-ascii; NAME=diff-1.59
Content-ID: [EMAIL PROTECTED]
Content-Description:
Index: src/modules/standard/mod_log_config.c
===
RCS file: /cvs/apache-1.3/src/modules/standard/mod_log_config.c,v
retrieving revision 1.59
diff -c -r1.59 mod_log_config.c
*** mod_log_config.c 1998/05/29 08:18:51 1.59
--- mod_log_config.c 1998/06/11 08:54:02
***
*** 215,220
--- 215,221
*/
typedef struct {
+ char *default_format_string;
array_header *default_format;
array_header *config_logs;
array_header *server_config_logs;
***
*** 232,237
--- 233,239
typedef struct {
char *fname;
+ char *format_string;
array_header *format;
int log_fd;
#ifdef BUFFERED_LOGS
***
*** 782,787
--- 784,790
multi_log_state *mls = (multi_log_state *) ap_palloc(p,
sizeof(multi_log_state));
mls-config_logs = ap_make_array(p, 1, sizeof(config_log_state));
+ mls-default_format_string = NULL;
mls-default_format = NULL;
mls-server_config_logs = NULL;
mls-formats = ap_make_table(p, 4);
***
*** 803,808
--- 806,812
add-server_config_logs = base-config_logs;
if (!add-default_format) {
+ add-default_format_string = base-default_format_string;
add-default_format = base-default_format;
}
add-formats = ap_overlay_tables(p, base-formats, add-formats);
***
*** 817,823
char *name)
{
const char *err_string = NULL;
- char *format;
multi_log_state *mls = ap_get_module_config(cmd-server-module_config,
config_log_module);
--- 821,826
***
*** 833,846
}
}
else {
! /*
! * See if we were given a name rather than a format string.
! */
! format = ap_table_get(mls-formats, fmt);
! if (format == NULL) {
! format = fmt;
! }
! mls-default_format = parse_log_string(cmd-pool, format,
err_string);
}
return err_string;
}
--- 836,843
}
}
else {
! mls-default_format_string = fmt;
! mls-default_format = parse_log_string(cmd-pool, fmt, err_string);
}
return err_string;
}
***
*** 852,868
multi_log_state *mls = ap_get_module_config(cmd-server-module_config,
config_log_module);
config_log_state *cls;
- char *format;
cls = (config_log_state *) ap_push_array(mls-config_logs);
cls-fname = fn;
if (!fmt) {
cls-format = NULL;
}
else {
! format = ap_table_get(mls-formats, fmt);
! format = (format != NULL) ? format : fmt;
! cls-format = parse_log_string(cmd-pool, format, err_string);
}
cls-log_fd = -1;
--- 849,863
multi_log_state *mls = ap_get_module_config(cmd-server-module_config,
config_log_module);
config_log_state *cls;
cls = (config_log_state *) ap_push_array(mls-config_logs);
cls-fname = fn;
+ cls
Re: mod_info/2415: /server-info doesn't check for the virtual host to list the info
The following reply was made to PR mod_info/2415; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: mod_info/2415: /server-info doesn't check for the virtual host to list the info Date: Tue, 16 Jun 1998 23:58:45 -0700 (PDT) Actually everything is fine if people would just stop using the main server... the mistake is in not requiring people to use _default_ hosts. Dean On 11 Jun 1998 [EMAIL PROTECTED] wrote: This is more of a design flaw than a bug; it's not as simple as that because some things are inherited by vhosts from the default server config, and some things aren't. I thought we had a report of it already, but I can't find it now - so I'm marking this as suspended so it can be investigated in the next coding cycle. Thanks for the report!
Re: os-solaris/2430: Not enough file descriptors??
The following reply was made to PR os-solaris/2430; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Joe Kupiszewski [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/2430: Not enough file descriptors?? Date: Wed, 17 Jun 1998 00:08:49 -0700 (PDT) On 12 Jun 1998, Joe Kupiszewski wrote: [Thu Jun 11 11:26:55 1998] [error] (24)Too many open files: unable to open a file descriptor above 15, you may need to increase the number of descriptors That's a warning that was added to help folks diagnose when they're too close to the file descriptor limit. I suppose it should say [warn], eh? 1.2.x don't give the warning even though they may be that close as well. Dean
Re: general/2441: entries in log files appear widely out of order, sometimes not at all
The following reply was made to PR general/2441; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jay Richmond [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2441: entries in log files appear widely out of order, sometimes not at all Date: Wed, 17 Jun 1998 00:19:46 -0700 (PDT) If I had to guess I'd say the freebsd port includes -DBUFFERED_LOGS. If so, they should be taken out and shot. twice. I don't have access to freebsd, so someone else will have to check. Dean
Re: other/2433: file http_main.c, line 2978, assertion old_listeners == NULL failed
The following reply was made to PR os-aix/2433; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Dan Cote [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: other/2433: file http_main.c, line 2978, assertion old_listeners == NULL failed Date: Wed, 17 Jun 1998 00:15:07 -0700 (PDT) Are you using any cc -O optimization? Does the problem go away if you remove the optimization option? Dean
Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding
The following reply was made to PR os-solaris/2386; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jason Spears [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding Date: Wed, 17 Jun 1998 00:31:15 -0700 (PDT) BTW... a standard question I forgot to ask: Is your ServerRoot on NFS? If so you need to use the LockFile directive to move the lock file. Dean
Re: general/2452: httpd eats all CPU!! - critical problem (fwd)
The following reply was made to PR general/2452; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: general/2452: httpd eats all CPU!! - critical problem (fwd) Date: Wed, 17 Jun 1998 11:39:09 -0700 (PDT) -- Forwarded message -- Date: Wed, 17 Jun 1998 20:05:53 +0200 To: Dean Gaudet [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2452: httpd eats all CPU!! - critical problem From: Rainer Scherg [EMAIL PROTECTED] Dean Gaudet schrieb: Is your ServerRoot on NFS? If so try using the LockFile directive. Hello! Sorry - No, the filesystem is on an internal harddisk (no remote mounts for webserver directories)... To keep it short, a list what I've tried or I'm still doing to track down the problem: - Checked all(?) hints on the apache bugdb dejanews (done) - Performance hints from the FAQ (done and still doing) - Checked the configs (done some tune up) - Track down the problem using truss and lsof (still working on) - Tried to alter the apache code (insert debug code) no luck so far... We are using the apache for intranet servers and as virtual intranet (all servers are virtual) proxy1 = intranet proxy, proxy2 = authentification proxy for internet firewall But as far as I can say at this moment, the problem seems to be located in the proxy functionality. Apache is fast in serving intranet pages (own pages). Requests for web pages via the proxies seems to be too slow (compared to a direct access to the firewall proxy). It seems to me very odd, that apache (10 active, 3 idle) can spiral down a Sparc 1000 (3 CPUs, 512 MB, 50 GB HD). At this moment we'll bind apache to only one cpu (pbind -cmd), so that the server will not be totally jammed - but this is no solution. I'm still trying to track down the problem, any ideas how it nailed down? Tnx for help! - Rainer
Re: mod_proxy/2422: your bug report to apache...
The following reply was made to PR mod_proxy/2422; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Alvaro Martinez Echevarria [EMAIL PROTECTED], Eric Raskin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_proxy/2422: your bug report to apache... Date: Mon, 15 Jun 1998 18:18:04 -0700 (PDT) I'm tempted to say we should just document this rather than attempt to work around it. Unless someone can find a cheap test to implement. Dean
Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding
The following reply was made to PR os-solaris/2386; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jason Spears [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding Date: Tue, 16 Jun 1998 12:05:54 -0700 (PDT) You may also want to try solaris specific newsgroups to see if anyone else is running into it. Dean
Re: protocol/2385: microsoft proxy server and apache 1.3 don't seem to get along
The following reply was made to PR protocol/2385; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: David Birnbaum [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: protocol/2385: microsoft proxy server and apache 1.3 don't seem to get along Date: Wed, 10 Jun 1998 00:17:07 -0700 (PDT) On Wed, 10 Jun 1998, David Birnbaum wrote: anything I can do to improve performace is key. Is it possible to do KeepAlive filtering on *any* Via header, or perhaps by remote IP address? Sure I was going to suggest using SetEnvIf Via IPSERV:8080 nokeepalive... that's when I noticed there wasn't a product token, so we can't solve the problem in general for this broken proxy. I'm gonna go see what rfc1945 and 2068 and such say for this case. Dean
Re: general/2396: Proposal for TimeZone directive
The following reply was made to PR general/2396; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: M.D.Parker [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2396: Proposal for TimeZone directive Date: Wed, 10 Jun 1998 01:39:47 -0700 (PDT) You can't change locale and timezones efficiently on all unixes. This is non-trivial to do portably. There are other similar requests in the database in the suspended state. However it's something that could be attempted as an extension to NSPR... Dean
Re: general/2394: Content-Type header info converted to lowercase
The following reply was made to PR general/2394; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: Shawn Stepper [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: general/2394: Content-Type header info converted to lowercase
Date: Wed, 10 Jun 1998 02:09:31 -0700 (PDT)
Bleh. Try this patch.
Dean
Index: include/httpd.h
===
RCS file: /export/home/cvs/apache-1.3/src/include/httpd.h,v
retrieving revision 1.222
diff -u -r1.222 httpd.h
--- httpd.h1998/06/07 01:22:36 1.222
+++ httpd.h1998/06/10 08:57:15
@@ -896,6 +896,7 @@
API_EXPORT(char *) ap_pregsub(pool *p, const char *input, const char *source,
size_t nmatch, regmatch_t pmatch[]);
+API_EXPORT(void) ap_content_type_tolower(char *);
API_EXPORT(void) ap_str_tolower(char *);
API_EXPORT(int) ap_ind(const char *, char); /* Sigh... */
API_EXPORT(int) ap_rind(const char *, char);
Index: main/util.c
===
RCS file: /export/home/cvs/apache-1.3/src/main/util.c,v
retrieving revision 1.119
diff -u -r1.119 util.c
--- util.c 1998/06/06 19:30:48 1.119
+++ util.c 1998/06/10 08:57:16
@@ -1781,3 +1781,27 @@
return (time1 - time0);
}
#endif
+
+/* we want to downcase the type/subtype for comparison purposes
+ * but nothing else because ;parameter=foo values are case sensitive.
+ * XXX: in truth we want to downcase parameter names... but really,
+ * apache has never handled parameters and such correctly. You
+ * also need to compress spaces and such to be able to compare
+ * properly. -djg
+ */
+API_EXPORT(void) ap_content_type_tolower(char *str)
+{
+char *semi;
+
+semi = strchr(str, ';');
+if (semi) {
+ *semi = '\0';
+}
+while (*str) {
+ *str = tolower(*str);
+ ++str;
+}
+if (semi) {
+ *semi = ';';
+}
+}
Index: main/util_script.c
===
RCS file: /export/home/cvs/apache-1.3/src/main/util_script.c,v
retrieving revision 1.115
diff -u -r1.115 util_script.c
--- util_script.c 1998/05/28 23:26:41 1.115
+++ util_script.c 1998/06/10 08:57:16
@@ -466,7 +466,7 @@
*endp-- = '\0';
r-content_type = ap_pstrdup(r-pool, l);
- ap_str_tolower(r-content_type);
+ ap_content_type_tolower(r-content_type);
}
/*
* If the script returned a specific status, that's what
Index: modules/standard/mod_cern_meta.c
===
RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_cern_meta.c,v
retrieving revision 1.29
diff -u -r1.29 mod_cern_meta.c
--- mod_cern_meta.c1998/06/09 05:22:11 1.29
+++ mod_cern_meta.c1998/06/10 08:57:17
@@ -269,7 +269,7 @@
*endp-- = '\0';
r-content_type = ap_pstrdup(r-pool, l);
- ap_str_tolower(r-content_type);
+ ap_content_type_tolower(r-content_type);
}
else if (!strcasecmp(w, Status)) {
sscanf(l, %d, r-status);
Index: modules/standard/mod_mime_magic.c
===
RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_mime_magic.c,v
retrieving revision 1.33
diff -u -r1.33 mod_mime_magic.c
--- mod_mime_magic.c 1998/05/28 22:09:57 1.33
+++ mod_mime_magic.c 1998/06/10 08:57:17
@@ -816,7 +816,7 @@
r-content_type = rsl_strdup(r, type_frag, type_pos, type_len);
/* XXX: this could be done at config time I'm sure... but I'm
* confused by all this magic_rsl stuff. -djg */
- ap_str_tolower(r-content_type);
+ ap_content_type_tolower(r-content_type);
}
if (state == rsl_encoding) {
r-content_encoding = rsl_strdup(r, encoding_frag,
Re: mod_log-any/2090: LogFormat directives are not inherited
The following reply was made to PR mod_log-any/2090; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Oliver von Bueren [EMAIL PROTECTED] Cc: M. D. Parker [EMAIL PROTECTED], Johnie Ingram [EMAIL PROTECTED], Christof Damian [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: mod_log-any/2090: LogFormat directives are not inherited Date: Wed, 10 Jun 1998 13:39:15 -0700 (PDT) Christof -- a small bug in your patch. I think you need to delay the parsing of log formats until the open_multi_logs point like I suggested, rather than in the merging point... because the main server is never merged (there's nothing to merge into it). Can I trouble you to fix that?= =20 :)=20 Dean On Wed, 10 Jun 1998, Oliver von Bueren wrote: Hello Everybody. =20 On Tue, 9 Jun 98 16:39:02 PDT, you wrote: =20 There is a patch apparently made available to me for testing, in the bug reportand for me IT WORKS! It can be used in the 1.3.0 release server as well. The patch is contained in my problem report on the Apache web site (PR#2090) =20 Thanks for the pointer, applied and tested it too. It works for all virtual hosts but it broke the logfile outside a virtualhost definition. Now this file has just the text common in it. Don't have time to look into it any closer but if you need more informaten just ask. =20 =20 Cheers, Oliver =20 /-\ =A6 Oliver von Bueren[EMAIL PROTECTED] = =A6 =A6 Schlierenstr. 42 www.ovb.ch = =A6 =A6 8142 UitikonSwitzerland = =A6 =A6 VoicePhone: ++41-1-4958181 = =A6 =A6 Attention: TimeZone GMT+1 - VoiceCalls only 09.00-21.00 local time = =A6 \-/ =20
Re: os-irix/2405: Apache isn't responding correctly to SIGHUP.
The following reply was made to PR os-irix/2405; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Lars Kellogg-Stedman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-irix/2405: Apache isn't responding correctly to SIGHUP. Date: Wed, 10 Jun 1998 13:53:50 -0700 (PDT) Try adding: EXTRA_CFLAGS=-DUSE_FCNTL_SERIALIZED_ACCEPT or EXTRA_CFLAGS=-DUSE_USLOCK_SERIALIZED_ACCEPT to your src/Configuration file and recompiling. Tell us how it goes, thanks. Dean
Re: mod_log-any/2090: LogFormat directives are not inherited
The following reply was made to PR mod_log-any/2090; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: M.D.Parker [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_log-any/2090: LogFormat directives are not inherited
Date: Mon, 8 Jun 1998 21:45:36 -0700 (PDT)
Here is a patch provided by Christof Damian [EMAIL PROTECTED]. It
has been applied to 1.3.1-dev... you can pick up a snapshot at
ftp://dev.apache.org/httpd/from-cvs/ in a few hours.
Tell me if it solves your problem.
Thanks
Dean
*** mod_log_config.c-orig Sun Jun 7 12:28:50 1998
--- mod_log_config.c Sun Jun 7 12:48:36 1998
***
*** 215,220
--- 215,221
*/
typedef struct {
+ char *default_format_string;
array_header *default_format;
array_header *config_logs;
array_header *server_config_logs;
***
*** 232,237
--- 233,239
typedef struct {
char *fname;
+ char *format_string;
array_header *format;
int log_fd;
#ifdef BUFFERED_LOGS
***
*** 782,787
--- 784,790
multi_log_state *mls = (multi_log_state *) ap_palloc(p,
sizeof(multi_log_state));
mls-config_logs = ap_make_array(p, 1, sizeof(config_log_state));
+ mls-default_format_string = NULL;
mls-default_format = NULL;
mls-server_config_logs = NULL;
mls-formats = ap_make_table(p, 4);
***
*** 800,812
--- 803,841
{
multi_log_state *base = (multi_log_state *) basev;
multi_log_state *add = (multi_log_state *) addv;
+ char *format;
+ const char *dummy;
add-server_config_logs = base-config_logs;
if (!add-default_format) {
+ add-default_format_string = base-default_format_string;
add-default_format = base-default_format;
}
add-formats = ap_overlay_tables(p, base-formats, add-formats);
+ if (add-default_format_string) {
+ format = ap_table_get(add-formats, add-default_format_string);
+ if (format) {
+ add-default_format = parse_log_string(p, format, dummy);
+ };
+ }
+
+ if (add-config_logs) {
+ config_log_state *clsarray = (config_log_state *)
add-config_logs-elts;
+ int i;
+
+ for (i = 0; i add-config_logs-nelts; ++i) {
+ config_log_state *cls = clsarray[i];
+
+ if (cls-format_string) {
+ format = ap_table_get(add-formats, cls-format_string);
+ if (format) {
+ cls-format = parse_log_string(p, format , dummy);
+ }
+ }
+ }
+ }
+
return add;
}
***
*** 817,823
char *name)
{
const char *err_string = NULL;
- char *format;
multi_log_state *mls = ap_get_module_config(cmd-server-module_config,
config_log_module);
--- 846,851
***
*** 833,846
}
}
else {
! /*
! * See if we were given a name rather than a format string.
! */
! format = ap_table_get(mls-formats, fmt);
! if (format == NULL) {
! format = fmt;
! }
! mls-default_format = parse_log_string(cmd-pool, format,
err_string);
}
return err_string;
}
--- 861,868
}
}
else {
! mls-default_format_string = fmt;
! mls-default_format = parse_log_string(cmd-pool, fmt, err_string);
}
return err_string;
}
***
*** 852,868
multi_log_state *mls = ap_get_module_config(cmd-server-module_config,
config_log_module);
config_log_state *cls;
- char *format;
cls = (config_log_state *) ap_push_array(mls-config_logs);
cls-fname = fn;
if (!fmt) {
cls-format = NULL;
}
else {
! format = ap_table_get(mls-formats, fmt);
! format = (format != NULL) ? format : fmt;
! cls-format = parse_log_string(cmd-pool, format, err_string);
}
cls-log_fd = -1;
--- 874,888
multi_log_state *mls = ap_get_module_config(cmd-server-module_config,
config_log_module);
config_log_state *cls;
cls = (config_log_state *) ap_push_array(mls-config_logs);
cls-fname = fn;
+ cls-format_string = fmt;
if (!fmt) {
cls-format = NULL;
}
else {
! cls-format = parse_log_string(cmd-pool, fmt, err_string);
}
cls-log_fd = -1;
Re: protocol/2385: microsoft proxy server and apache 1.3 don't seem to get along
The following reply was made to PR protocol/2385; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: David Birnbaum [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: protocol/2385: microsoft proxy server and apache 1.3 don't seem to get along Date: Mon, 8 Jun 1998 23:06:12 -0700 (PDT) Oh god. Just what I want. To help microsoft debug their protocol stack. Again. Ok ok, I'll give 'em the benefit of the doubt. When they released MSIE 4.0 we only helped them find 4 gross bugs in their code which made it completely obvious that they'd never even considered testing against the world's most popular web server... in exchange we found one subtle bug in apache months later. On 8 Jun 1998, David Birnbaum wrote: 1. When the person tries to connect, first couple of connections (the page and the first one or two gifs on the page) load immediately; after that, each connection (page/GIF) loads at 15 second intervals, two or three at a time. This sounds like their proxy doesn't correctly figure out that it's supposed to have a persistent connection going. 3. When a client is bringing up other sites (www.sun.com, www.microsoft.com) WHILE we are talking to our site, they are slow. As soon as our page finishes coming in, things speed back up to normal. Sounds like their proxy has some interesting potential DoS attacks. We'll ignore that for now. Ok. Time to get down and dirty with tcpdump. Suppose this is the setup: client --net 1-- proxy --net 2-- origin server Let's start with a tcpdump on net 2. We may eventually want to look at net 1 -- but we won't do that unless we're totally boggled at what we see on net 2. The easiest way to do this is probably right on the origin server itself, since it's running Unix... right? If you're Windows end-to-end then I'm not sure how to help ;) On the client, exit your browser. And maybe restart the proxy if you can. I want to be sure there are no connections to the origin server. On the origin server do this: tcpdump -w /tmp/dump.out -s 1544 tcp port 80 and host proxy.addr.here Start that up. Then start the client, and request a page. Wait for the whole sequence to complete. Then hit ^C on the tcpdump. Hopefully /tmp/dump.out isn't too large... if it's small, say under 40k then mail it to us. Otherwise put it on a website somewhere and mail us the URL. Other data that we'll need: ip address of the origin server ip address of the proxy server Thanks! Dean
Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding
The following reply was made to PR os-solaris/2386; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jason Spears [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-solaris/2386: many connections stuck in CLOSE_WAIT, all servers on machine appear to stop responding Date: Mon, 8 Jun 1998 23:23:57 -0700 (PDT) Were you running 1.2.6 before? There were some changes during the 1.2.x series that may be relevant... and if you're not running 1.2.6 it would be nice to know if that works. Dean
Re: config/2372: If libcrypt is installed, it will be used even if compiling for libc5
The following reply was made to PR config/2372; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Steve Baur [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: config/2372: If libcrypt is installed, it will be used even if compiling for libc5 Date: Sun, 7 Jun 1998 22:53:17 -0700 (PDT) On 8 Jun 1998, Steve Baur wrote: + doing sanity check on compiler and options ld: warning: libc.so.6, needed by /usr/lib/libcrypt.so, may conflict with libc.so.5 The Linux test for detecting -lcrypt is too aggressive. I have all compiler options set to values which worked for building against libc5 on a libc6 system (it worked in 1.2.6), except that -lcrypt gets detected (it's there) even when I try to make a libc5 binary. Actually, no, I'd be more tempted to say that if your compiler can find a libcrypt which doesn't work with the settings you gave, then that's a problem with the settings you gave. There's nothing we can do to work around broken compiler settings... Libc6 is not ready for prime time, I'd suggest forcing the installer to put -lcrypt in one of the Configuration flags. I would have agreed with you three months ago. But redhat's 2.0.7-13 has been just fine to me... We won't remove the libcrypt autodetection. It's a FAQ for folks building 1.2 on redhat, it wastes our time dealing with people who don't add -lcrypt. This is a transitional period, yeah it hurts. Six months from now we'd be flogging a dead horse by still requiring folks to add -lcrypt. Dean
Re: config/2372: If libcrypt is installed, it will be used even if compiling for libc5
The following reply was made to PR config/2372; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: SL Baur [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: config/2372: If libcrypt is installed, it will be used even if compiling for libc5 Date: Sun, 7 Jun 1998 23:24:24 -0700 (PDT) On 7 Jun 1998, SL Baur wrote: My compiler settings were not broken though. After I hand-edited all the Makefiles to remove the spurious -lcrypt's which Configure added, it built (and ran) correctly under libc5. Yes, your compiler settings are wrong if adding -lcrypt to them causes them to load a crypt library that doesn't work. The correct way to do what you're doing is to create a new gcc specs file which does not have /usr/lib in it at all. It should have /usr/i486-unknown-linux/lib in it only (or wherever you put your libc5). It should also avoid /usr/include entirely... otherwise you could end up with a header mismatch -- and the result would be far worse than using glibc2 in the first place. To be honest, I've never been happy with a system with both glibc2 and lib5. Believe me, I've tried. I support apache on both platforms, and I'd love to have them both on the same system to simplify development and testing. But there are just too many little problems that happen that I gave up on it... after wasting a lot of time with specs files, and rebuilding libraries and crap like that. You, me, and probably 20 other people use this configuration. There are thousands that use libc5-only, and thousands more that use glibc2-only. I have no motivation to support a tiny fraction of the population using an interim solution. Dean
Re: mod_log-any/2229: Some log entries do not have full IP address
The following reply was made to PR mod_log-any/2229; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Wei Lin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2229: Some log entries do not have full IP address Date: Sun, 7 Jun 1998 23:29:40 -0700 (PDT) Try this patch. mod_usertrack was corrupting the hostname. Dean Index: modules/standard/mod_usertrack.c === RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_usertrack.c,v retrieving revision 1.34 diff -u -r1.34 mod_usertrack.c --- mod_usertrack.c1998/04/11 12:00:53 1.34 +++ mod_usertrack.c1998/06/08 06:08:56 @@ -137,13 +137,9 @@ /* 1024 == hardcoded constant */ char cookiebuf[1024]; char *new_cookie; -char *dot; const char *rname = ap_get_remote_host(r-connection, r-per_dir_config, REMOTE_NAME); -if ((dot = strchr(rname, '.'))) -*dot = '\0';/* First bit of hostname */ - #if defined(NO_GETTIMEOFDAY) !defined(NO_TIMES) /* We lack gettimeofday(), so we must use time() to obtain the epoch seconds, and then times() to obtain CPU clock ticks (milliseconds). @@ -151,7 +147,7 @@ mpe_times = times(mpe_tms); -ap_snprintf(cookiebuf, sizeof(cookiebuf), %s%d%ld%ld, rname, (int) getpid(), +ap_snprintf(cookiebuf, sizeof(cookiebuf), %s.%d%ld%ld, rname, (int) getpid(), (long) r-request_time, (long) mpe_tms.tms_utime); #elif defined(WIN32) /* @@ -160,13 +156,13 @@ * was started. It should be relatively unique. */ -ap_snprintf(cookiebuf, sizeof(cookiebuf), %s%d%ld%ld, rname, (int) getpid(), +ap_snprintf(cookiebuf, sizeof(cookiebuf), %s.%d%ld%ld, rname, (int) getpid(), (long) r-request_time, (long) GetTickCount()); #else gettimeofday(tv, tz); -ap_snprintf(cookiebuf, sizeof(cookiebuf), %s%d%ld%d, rname, (int) getpid(), +ap_snprintf(cookiebuf, sizeof(cookiebuf), %s.%d%ld%d, rname, (int) getpid(), (long) tv.tv_sec, (int) tv.tv_usec / 1000); #endif
Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads
The following reply was made to PR mod_log-any/2366; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Glenn Fleishman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads Date: Mon, 8 Jun 1998 10:49:43 -0700 (PDT) That was a deliberate change... it shouldn't break anything, the cookie value is just an opaque token that's supposed to differ from one client to another. Is it causing you trouble? Dean On Mon, 8 Jun 1998, Glenn Fleishman wrote: Sorry, I was wrong about one thing. The code change in user track now makes visit cookies (Apache=) that weren't in the same format as 1.2. In 1.2, just the first part (hostname or first number in dotted quad) were concatenated with the tick counter. But with this code change, the logging now works (I see how those two issues are related) but the cookie contains the entire FQDN or IP number. Glenn Fleishman, unsolicited pundit. see my mug: http://www.glenns.org freelance technical writer, perl hacker, Adobe Magazine columnist/editor co-author of Real World Scanning Halftones, 2d edition http://rwsh.com technical director, Phinney-Bischoff Design Househttp://www.pbdh.com director of operations, i/us Corporation http://www.i-us.com chair, Web Marketing '98/D.C. http://www.thunderlizard.com/webmarketing/
Re: config/2319: last awk script in configure breaks with braindead awks
The following reply was made to PR config/2319; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: config/2319: last awk script in configure breaks with braindead awks Date: Mon, 8 Jun 1998 13:41:46 -0700 (PDT) Committed, thanks. Dean On Mon, 8 Jun 1998 [EMAIL PROTECTED] wrote: On May 29, 8:47pm, [EMAIL PROTECTED] wrote: Synopsis: last awk script in configure breaks with braindead awks State-Changed-From-To: open-closed State-Changed-By: rse State-Changed-When: Fri May 29 13:47:56 PDT 1998 State-Changed-Why: Thanks for your report. Your patch was enhanced by me to also try GNU awk (gawk) and was comitted to the Apache source repository now. It occurs in Apache 1.3. Thanks. (NOTE: I was going to submit a new bug report on this but my web browser says there's no DNS entry for bugs.apache.org this morning (or dev.apache.org for that matter)). Oh oh, this has now been done incorrectly. Sometime in the last three 3 days a program findprg.sh has been introduced into the 1.3.1 snapshot. It doesn't behave as expected. When findprg.sh looks for nawk gawk awk but it finds awk in the PATH before nawk, it uses awk. Below is a possible fix (change the ordering of the loops). - Dave Dykstra *** findprg.sh.O Mon Jun 8 10:48:09 1998 --- findprg.sh Mon Jun 8 10:49:55 1998 *** *** 43,56 fi rm -f $testfile ! # iterate over paths ! for path in `echo $pathlist |\ ! sed -e 's/^:/.:/' \ ! -e 's/::/:.:/g' \ ! -e 's/:$/:./' \ ! -e 's/:/ /g'`; do ! # iterate over names ! for name in $namelist; do if [ $minusx $path/$name ] [ ! -d $path/$name ]; then if [ $silent != yes ]; then echo $path/$name --- 43,57 fi rm -f $testfile ! paths=`echo $pathlist |\ ! sed -e 's/^:/.:/' \ ! -e 's/::/:.:/g' \ ! -e 's/:$/:./' \ ! -e 's/:/ /g'` ! # iterate over names ! for name in $namelist; do ! # iterate over paths ! for path in $paths; do if [ $minusx $path/$name ] [ ! -d $path/$name ]; then if [ $silent != yes ]; then echo $path/$name
Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads
The following reply was made to PR mod_log-any/2366; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Glenn Fleishman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads Date: Sat, 6 Jun 1998 18:26:34 -0700 (PDT) I don't use the new configuration stuff, I don't know how to do it either. You can still use the old configuration stuff. And in that, you should put: EXTRA_LIBS=-L/usr/local/bind/lib -lbind EXTRA_CFLAGS=-I/usr/local/bind/include Tell us how that goes... Dean
Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads
The following reply was made to PR mod_log-any/2366; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Glenn Fleishman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads Date: Sat, 6 Jun 1998 20:54:54 -0700 (PDT) I honestly don't know what to say. The problem doesn't happen anywhere except sunos 4.x, so I'd say it's a problem on that system... and there's not anything I know to work around it in apache... maybe you can pester folks on a sunos 4.x specific mailing-list/newsgroup. Someone else has to have solved this issue. Dean On Sat, 6 Jun 1998, Glenn Fleishman wrote: EXTRA_LIBS=-L/usr/local/bind/lib -lbind EXTRA_CFLAGS=-I/usr/local/bind/include These flags can be added to src/Makefile after running configure and they get used. The executable ballooned in size: Before -rwxr-xr-x 1 root 499712 Jun 6 17:20 /usr/apache13/sbin/httpd After -rwxr-xr-x 1 root 1146880 Jun 6 20:05 src/httpd However, it did work just fine - but the problem persists. Still getting just the fragment. Thanks. Glenn Fleishman, unsolicited pundit. see my mug: http://www.glenns.org freelance technical writer, perl hacker, Adobe Magazine columnist/editor co-author of Real World Scanning Halftones, 2d edition http://rwsh.com technical director, Phinney-Bischoff Design Househttp://www.pbdh.com director of operations, i/us Corporation http://www.i-us.com chair, Web Marketing '98/D.C. http://www.thunderlizard.com/webmarketing/
Re: mod_log-any/2352: The limited number of VIRTUAL DOMAINS...
The following reply was made to PR mod_log-any/2352; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Curtis Wood [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2352: The limited number of VIRTUAL DOMAINS... Date: Sat, 6 Jun 1998 12:39:35 -0700 (PDT) On 4 Jun 1998, Curtis Wood wrote: I'm assuming that the reasoning behind keeping the file descriptors open for each and every log is for speed, not having to open and close the file each and every time the given log has to be updated, seems logical. It's also for security. The children do not run as root. Unless you use suexec, CGIs run as the same uid as the children. Therefore if the children can open logs to write on them, then so could CGIs. This could compromise the logs. more servers requiring access to the same log at the same time. The solution comes from having an external application do all the logging and communicate with all the servers via a message que. This is what piped logs are for. Dean
Re: config/2363: Alias and ScriptAlias cannot handle symbolic link in realname
The following reply was made to PR config/2363; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Maro Shim [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: config/2363: Alias and ScriptAlias cannot handle symbolic link in realname Date: Sat, 6 Jun 1998 12:44:46 -0700 (PDT) Apache can handle symbolic links, but there is a default section in the distributed access.conf-dist file: Directory / Options None AllowOverride None /Directory Which disables symlinks. You have to re-enable them. Try changing Options None to Options FollowSymLinks. Dean
Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads
The following reply was made to PR mod_log-any/2366; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Glenn Fleishman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads Date: Sat, 6 Jun 1998 12:50:54 -0700 (PDT) Did you link against the bind libraries explicitly? Sunos 4.x has some very interesting ideas w.r.t. name lookup, DNS, and NIS/YP. In particular, things should work fine if you use the bind libraries explicitly. Or if you don't use NIS/YP. Also take a peek in your /etc/hosts to see if you've got all the entries listed with the FQDN first. Dean
Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads
The following reply was made to PR mod_log-any/2366; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Glenn Fleishman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_log-any/2366: DNS lookup in logs reports host, first number in dotted quads Date: Sat, 6 Jun 1998 13:15:34 -0700 (PDT) On Sat, 6 Jun 1998, Glenn Fleishman wrote: On the bind subject: I didn't do it explicitly, but apache is performing lookups in some cases, just not all. How do I link explicitly? In all the software I've compiled over the last four years, this hasn't been a problem with this OS (or I've been lucky). It depends on how you've got it installed. If you've got the resolv+ package installed then you probably linked against it, since that modifies the shared libcs. But otherwise I think you need to add -lresolv or something like that, it's been a long time since I've had to deal with sunos4. On the NIS/YP front: we use it, but barely. Just enough to avoid having to replace it, but not for any real purpose. It's set up to use DNS primarily. Yeah that's enough to cause troubles. /etc/hosts: not sure why this affects externally looked-up FQDNs - can you explain? Does an FQDN in the /etc/hosts file force DNS involvement in resolver lookups? That seems odd. It won't affect external stuff. It'll only affect stuff that has entries in /etc/hosts. Dean
Re: general/1973: bind: Address family not supported by protocol family, httpd: could not bind to port 80
The following reply was made to PR general/1973; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Klaus Weber [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/1973: bind: Address family not supported by protocol family, httpd: could not bind to port 80 Date: Thu, 4 Jun 1998 13:55:36 -0700 (PDT) On 2 Jun 1998, Klaus Weber wrote: The following fixes solved the problem on MPRAS. please note, it is actually not advisable to check for MPRAS, sinde GuessOS returns i486-ncr-sysv4 on all NCR systems running under SVR4. I'd like to apply your patch, but I'm confused. It seems that you're changing behaviour for all NCR SVR4 systems rather than just the MPRAS system that you say has the problem. Maybe you could improve GuessOS to return more information if you need it to distinguish between different NCR systems? Or, does the problem exist in all NCR systems? Thanks Dean
Re: config/2309: SERVER_SUBVERSION disappears but there is NO replacement
The following reply was made to PR config/2309; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: config/2309: SERVER_SUBVERSION disappears but there is NO replacement Date: Thu, 28 May 1998 16:33:26 -0700 (PDT) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to [EMAIL PROTECTED] for more info. --CECD5AA1152E23C0AE1A0E4D Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: [EMAIL PROTECTED] Use mod_headers and create another header with your comment. Or write a module to add your comments. I don't see why we need to support Server modifications for folks who don't change the code at all. Dean --CECD5AA1152E23C0AE1A0E4D--
Re: config/2309: SERVER_SUBVERSION disappears but there is NO replacement
The following reply was made to PR config/2309; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: M. D. Parker [EMAIL PROTECTED] Cc: Lars Eilebrecht [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: config/2309: SERVER_SUBVERSION disappears but there is NO replacement Date: Thu, 28 May 1998 16:34:30 -0700 (PDT) If you're modifying the server anyhow then it's trivial for you to do this. If you're not modifying the server, I don't see what the need is. Dean
Re: apache-api/2283: Few changes to http_main.c and http_main.h
The following reply was made to PR apache-api/2283; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: apache-api/2283: Few changes to http_main.c and http_main.h Date: Thu, 28 May 1998 16:42:09 -0700 (PDT) For example, if you're exposing timeout() because you want to install a sigpipe/alrm handler and then restore timeout() later then you should use the result from signal() itself... as in: void (*old_handler)(int) = signal(SIGALRM, SIG_IGN); ... signal(SIGALRM, old_handler); And pconf is already available to modules. It is the pool passed to the init() method in the module_rec. Dean
RE: os-qnx/2296: SERIALIZED_ACCEPT on QNX
The following reply was made to PR os-qnx/2296; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Saccoccio, Robert [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: os-qnx/2296: SERIALIZED_ACCEPT on QNX Date: Fri, 29 May 1998 11:14:21 -0700 (PDT) On Fri, 29 May 1998, Saccoccio, Robert wrote: ...that many architectures behave more 'nicely' if we serialize even the single socket case. So this is actually the default in almost all cases. What suggests to you QNX should be an exception to this? I'm not suggesting it should be different, I'm just curious. Well I know some of the QNX developers and suspect they got things right ;) But really, the reason I did it, is to avoid a drastic change in behaviour for folks' current setups. Right now no QNX user has has the locking, and presumably has become accustomed to the performance of their server and hasn't had to place a LockFile anywhere in the filesystem yet... and if they used multiple sockets, with 1.3 betas it would have told them their config wouldn't work. So I just did that for the principle of least surprise. Dean
Re: mod_include/1921: '$' is not recognized as 'end of line' in regex matching
The following reply was made to PR mod_include/1921; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: Peter Jakobi [EMAIL PROTECTED]
Cc: Rubinstein Dmitry [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: mod_include/1921: '$' is not recognized as 'end of line' in regex
matching
Date: Mon, 25 May 1998 18:39:33 -0700 (PDT)
On Mon, 25 May 1998, Peter Jakobi wrote:
2249 mod_include 1.2.5 onward Noncr apache open sw-bug [EMAIL PROTECTED] SSI
regex error: /^$/ should only match undef'd or empty vars 2249
1921 Synopsis: '$' is not recognized as 'end of line' in regex matching
Try this... I screwed up during the security patches in 1.2.5. I've
already committed this fix to 1.2.7-dev and 1.3b8-dev. Tell me if it does
the job for you.
Dean
Index: modules/standard/mod_include.c
===
RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_include.c,v
retrieving revision 1.91
diff -u -r1.91 mod_include.c
--- mod_include.c 1998/05/20 19:41:11 1.91
+++ mod_include.c 1998/05/26 00:51:17
@@ -532,20 +532,26 @@
/* what a pain, too bad there's no table_getn where you can
* pass a non-nul terminated string */
l = end_of_var_name - start_of_var_name;
- l = (l sizeof(var) - 1) ? (sizeof(var) - 1) : l;
- memcpy(var, start_of_var_name, l);
- var[l] = '\0';
+ if (l != 0) {
+ l = (l sizeof(var) - 1) ? (sizeof(var) - 1) : l;
+ memcpy(var, start_of_var_name, l);
+ var[l] = '\0';
- val = table_get(r-subprocess_env, var);
- if (val) {
- expansion = val;
- l = strlen(expansion);
+ val = table_get(r-subprocess_env, var);
+ if (val) {
+ expansion = val;
+ l = strlen(expansion);
+ }
+ else if (leave_name) {
+ l = in - expansion;
+ }
+ else {
+ break; /* no expansion to be done */
+ }
}
- else if (leave_name) {
- l = in - expansion;
- }
else {
- break; /* no expansion to be done */
+ /* zero-length variable name causes just the $ to be copied
*/
+ l = 1;
}
l = (l end_out - next) ? (end_out - next) : l;
memcpy(next, expansion, l);
Re: os-irix/2244: GCC compile error, readv/writev
The following reply was made to PR os-irix/2244; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Justin Pope [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-irix/2244: GCC compile error, readv/writev Date: Mon, 25 May 1998 11:07:59 -0700 (PDT) This should be put in the FAQ so many people run into it. On 18 May 1998, Justin Pope wrote: Environment: IRIX 6.2, gcc 2.7.2.2 ... In file included from buff.c:66: /usr/include/sys/uio.h:34: conflicting types for `readv' /usr/ppco/GNU/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.2.f.2/include/unistd.h:157: previous declaration of `readv' IRIX version 6.2, gcc built against 5.3. This is wrong. gcc is intimately tied with the version of the operating system it is built for. Rebuild gcc on 6.2 and the problem will go away. You don't want to run with NO_WRITEV -- it can cause painful network traffic against HTTP/1.1 clients (IE4 for example). Dean
Re: general/2201: N/a
The following reply was made to PR general/2201; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: John Summerfield [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2201: N/a Date: Thu, 7 May 1998 02:18:37 -0700 (PDT) Unfortunately, the release is a freeform text field, and searching for bugs in 1.2.5 (for example) wouldn't show you everything in 1.2.5. The system just isn't sophisticated enough to track when particular bugs are fixed in a manner that would make this sort of query useful. Dean
mod_autoindex/2177: mod_autoindex (mod_dir) invokes other modules with timeouts in scope
Number: 2177 Category: mod_autoindex Synopsis: mod_autoindex (mod_dir) invokes other modules with timeouts in scope Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Sun May 3 00:30:00 PDT 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:all Environment: all Description: see index_directory(). Notice that it sets a hard_timeout and then it proceeds to do scads of sub_req_lookup_files. This is wrong. See http_main.h for a bit of an explanation of why. See also PR#2076. How-To-Repeat: Fix: do the timeout only when sending the directory contents Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Re: general/2144: apache always detaches for normal operation
The following reply was made to PR general/2144; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Janos Farkas [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2144: apache always detaches for normal operation Date: Mon, 27 Apr 1998 20:09:17 -0700 (PDT) 1.3 is in feature freeze... but if you want to work this out that's cool. If you resubmit the patch after 1.3.0 is released it stands a better chance of being incorporated. Dean
Re: mod_status/2138: mod_status always displays 256 possible connection slots
The following reply was made to PR mod_status/2138; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Tom Mornini [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_status/2138: mod_status always displays 256 possible connection slots Date: Sun, 26 Apr 1998 17:14:06 -0700 (PDT) I suppose yes this could be confusing. But there's a reason for it -- it has to do with graceful restarts. Suppose you were to change your MaxClients and then do a graceful restart. If you lower it you could possibly have children (gracefully exiting) numbered higher than the current MaxClients... so we'd need to keep some sort of history for MaxClients in order to figure out how much of the table to show. Dean
Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures
The following reply was made to PR suexec/1769; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures Date: Mon, 27 Apr 1998 11:32:21 -0700 (PDT) -- Forwarded message -- Date: Mon, 27 Apr 1998 12:12:49 -0400 To: [EMAIL PROTECTED] From: Jonathan Roy [EMAIL PROTECTED] I'd just like to second PR #1769's request for more flexability in suexec. The only thing I wanted to use it for was to set cgis in the adverts/ directory to their own user/group, one just for the ad engine, so other users couldn't screw it up with their own cgis (which would have the same permissions). Maybe 1.4 or 2.0 will have that I guess. Some sort of Directory based User/Group model. Then each seperate application could have it's own user/group permissions... -Jonathan -- Jonathan Roy - [EMAIL PROTECTED] - Idle Communications, Inc.
Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI
The following reply was made to PR mod_cgi/2127; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Ray Zimmerman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI Date: Thu, 23 Apr 1998 23:55:11 -0700 (PDT) Known; this is unchanged from 1.2. It's non-trivial to fix. Dean
general/2135: bug submission CGI should spot check the email address
Number: 2135 Category: general Synopsis: bug submission CGI should spot check the email address Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Fri Apr 24 00:00:03 PDT 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:n/a Environment: n/a Description: The bug submission CGI should spot check the email address to ensure that it matches /[EMAIL PROTECTED]/ ... which is a fairly liberal regex that should catch the most common user screwups. Maybe be nice, and strip leading and trailing spaces. Dean How-To-Repeat: Fix: Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Re: mod_userdir/2130: Netscape displays a .htm file as text only when retriving from UserDir space
The following reply was made to PR mod_userdir/2130; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Gary Marshall [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_userdir/2130: Netscape displays a .htm file as text only when retriving from UserDir space Date: Thu, 23 Apr 1998 23:53:57 -0700 (PDT) You have to clear the memory and disk caches to force netscape to re-read a content-type. So if you accidentally sent it text/plain once it'll think it's text/plain for eternity. Dean
Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI
The following reply was made to PR mod_cgi/2127; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Ray Zimmerman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI Date: Fri, 24 Apr 1998 12:15:56 -0700 (PDT) nph also means that the server isn't HTTP/1.1 compliant; and therefore it is broken. On Fri, 24 Apr 1998, Ray Zimmerman wrote: You say it's non-trivial to fix. There is a patch available (for 1.2.4) on the cgiAbort page at: http://wwwtest.gdb.org/browser/abort/cgiAbort.html Is there a problem with this fix? Yeah, it doesn't work. Consider the case where the CGI blocks forever but the client disappears. Consider the case where the client blocks forever but the CGI disappears. Either way you end up stuck in a read() or a write() call which won't return; and you can't detect that the other has disappeared. You either need to fork() another process to watch things; use another thread; or write a select() based loop. But if you read the documentation: The solution to this problem is for CGI scripts to write data periodically to the client browser's socket while a query is taking place. It turns out that CGI scripts do not write their output directly to a client browser's socket, but instead write (via a Unix pipe) to another process that buffers the output and sends it along to the client browser (there is a special class of scripts called nph-scripts that do write directly to the client, but that's another story). If a web server line buffers the output from a CGI script, when a single newline is written, it will be passed directly to the client browser. You'll discover that we already support this in 1.3. If you write your CGI to periodically send data then you will discover that your CGI is killed off. Notice that this patch only works for text/* content_types... and furthermore requires modification of the CGI -- not of apache. Dean
Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI
The following reply was made to PR mod_cgi/2127; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Marc Slemko [EMAIL PROTECTED] Cc: Apache bugs database [EMAIL PROTECTED], Ray Zimmerman [EMAIL PROTECTED] Subject: Re: mod_cgi/2127: Impossible to detect browser disconnect from CGI Date: Fri, 24 Apr 1998 13:02:28 -0700 (PDT) How about you deal with it then, I've got far too much to do this week. Dean On Fri, 24 Apr 1998, Marc Slemko wrote: On 24 Apr 1998, Dean Gaudet wrote: You'll discover that we already support this in 1.3. If you write your CGI to periodically send data then you will discover that your CGI is killed off. [...] But the reporter is saying that this _doesn't_ work for him in 1.3. I can't duplicate his results, but I haven't tried on Solaris. Look at the sample CGI he supplied.
Re: mod_autoindex/2112: Case-insensitive matching added in 1.2.6 isn't in 1.3b6.
The following reply was made to PR mod_autoindex/2112; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: David MacKenzie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_autoindex/2112: Case-insensitive matching added in 1.2.6 isn't in 1.3b6. Date: Wed, 22 Apr 1998 11:44:55 -0700 (PDT) All mime types are lower case in 1.3b6. This was a change to the API... it's mentioned somewhere in src/CHANGES. Dean
Re: mod_autoindex/2112: Case-insensitive matching added in 1.2.6 isn't in 1.3b6.
The following reply was made to PR mod_autoindex/2112; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: David MacKenzie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_autoindex/2112: Case-insensitive matching added in 1.2.6 isn't in 1.3b6. Date: Wed, 22 Apr 1998 11:45:39 -0700 (PDT) Er, what I mean... open reading a mime-type from the user it's mapped to lower case. But yeah this is probably still a bug. I need to wake up still. Dean
Re: general/2117: The CIDR syntax support for allow and deny finds the '/' in comments.
The following reply was made to PR general/2117; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: David J. MacKenzie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2117: The CIDR syntax support for allow and deny finds the '/' in comments. Date: Wed, 22 Apr 1998 12:43:05 -0700 (PDT) On Wed, 22 Apr 1998, David J. MacKenzie wrote: That's fine, but in that case apache should print reasonable error messages rejecting lines with trailing comments, not do undefined things with them (such as silently accept them in some cases and suddenly break upon a new release :-). Checking correctness seems be the apache approach to configuration file processing in other respects. It actually does a well defined thing with them... it treats them all as hostnames in this case. In general there's not much we can do without overhauling the config language -- because the RAW_ARGS style of commands can do almost anything they want. There's no well defined quoting style; and inadequate centralized parsing. It's somewhat difficult to shoehorn fixes into it. A rewrite is definately in order. Dean
Re: general/2117: The CIDR syntax support for allow and deny finds the '/' in comments.
The following reply was made to PR general/2117; it has been noted by GNATS.
From: Dean Gaudet [EMAIL PROTECTED]
To: David J. MacKenzie [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: general/2117: The CIDR syntax support for allow and deny finds the
'/' in comments.
Date: Wed, 22 Apr 1998 13:07:58 -0700 (PDT)
On 22 Apr 1998, David J. MacKenzie wrote:
int ap_hostname_syntax(char *s)
{
for (; *s; s++) {
/* Allow : for IPv6. */
if (!isalnum(*s) strchr(_-.:, *s) == NULL)
return 0;
}
return 1;
}
_ isn't valid though... I suppose we could do something like bind does
with it; complain but allow it.
Dean
mod_include/2076: mod_include timeouts are messed up
Number: 2076
Category: mod_include
Synopsis: mod_include timeouts are messed up
Confidential: no
Severity: non-critical
Priority: medium
Responsible:apache
State: open
Class: sw-bug
Submitter-Id: apache
Arrival-Date: Sat Apr 18 00:40:00 PDT 1998
Last-Modified:
Originator: [EMAIL PROTECTED]
Organization:
apache
Release:all through 1.3
Environment:
n/a
Description:
mod_include does a hard_timeout(), and then proceeds to invoke other
modules via sub_req_lookup_{uri,file}, and actually invoke other
handlers via run_sub_request(). This is all somewhat bogus -- because
modules frequently can't prepare themselves for timeouts occuring at
arbitrary points in the code. The timeouts should be disabled during
the nesting.
Ok that doesn't sound serious enough does it? Well what if I mention
that because timeouts *DON'T NEST* the mod_include timeout disappears
after the first nested include of almost any other module... i.e. it
disappears when the first ap_kill_timeout() happens. Just try it,
nested include something small followed by a lot of crap and disconnect
the ethernet from the client while the crap is being transmitted. There's
no outstanding timeout.
How-To-Repeat:
Fix:
yeah, disable timeouts before subrequests and re-enable them afterward
Audit-Trail:
Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include [EMAIL PROTECTED] in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
mod_log-any/2073: pipelined connections are not logged correctly
Number: 2073 Category: mod_log-any Synopsis: pipelined connections are not logged correctly Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Fri Apr 17 15:30:00 PDT 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.2, 1.3 Environment: all Description: When a connection is pipelined, Apache may log that a response was sent even before it has flushed the response to the kernel. So the response may never be sent, but will show in the log as having been sent. A less serious problem is that the duration of the request is wrong... but given that number is always wrong it's less of a concern (apache never knows when the kernel has actually sent the response). How-To-Repeat: Fix: One possible solution was implemented and posted to new-httpd, see Message-ID [EMAIL PROTECTED] in the february 1998 archives. However this solution has a rather large drawback in that it chews a bunch of memory because it needs to keep each request pool around as long as the request still has data in Apache's buffer. For future reference in API design, a less expensive solution is to do logging in two steps. One step happens at the end of the request, when the full request_rec is available. At this point the logger should not log -- it should be given another pool to allocate whatever it wants in. Then later when the response is actually flushed from Apache's buffers the logger should be called again and given the opportunity to log. That is to say, logging should become two phase. The first phase copies the relevant log data from the request_rec into another pool. That way the main request pool can be cleared to free up memory. Then the second phase actually performs the logging using the copied data Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Re: mod_log-any/2073: pipelined connections are not logged correctly
The following reply was made to PR mod_log-any/2073; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_log-any/2073: pipelined connections are not logged correctly Date: Fri, 17 Apr 1998 15:40:44 -0700 (PDT) Incidentally, I think this is more than just an issue for pipelined connections. The solutions I have so far are somewhat expensive though. But this problem is part of a more general problem of how do we deal with logging MUX connections. Also Marc suggested a server a while back where each request would have a thread dedicated to it long enough to figure out what file needs to be served; and then that would be passed to a central thread which multiplexed all the files being served. This model offers various performance advantages without adding complexity to the protocol code. But suffers from a similar problem as this logging issue. When the initial request processing happens a bunch of memory is allocated, and little of that is required to actually serve a static file and log that you served it. So yeah, this is non-critical in 1.2/1.3 but something to think about in the future. Dean
protocol/2065: using find_token() for If-Match et al is bogus
Number: 2065 Category: protocol Synopsis: using find_token() for If-Match et al is bogus Confidential: no Severity: non-critical Priority: medium Responsible:apache State: open Class: sw-bug Submitter-Id: apache Arrival-Date: Wed Apr 15 10:10:00 PDT 1998 Last-Modified: Originator: [EMAIL PROTECTED] Organization: apache Release:1.2 and 1.3 Environment: n/a Description: If a request includes the header: If-Match: abc def the code will do completely the wrong thing. It treats this as two tokens rather than one. The bug isn't in find_token(), the bug is in meets_conditions() which shouldn't be using find_token(). Another function, maybe called find_quoted_string() should be added and used. See these new-httpd messages: Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Dean How-To-Repeat: Fix: Audit-Trail: Unformatted: [In order for any reply to be added to the PR database, ] [you need to include [EMAIL PROTECTED] in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
Re: config/2005: Incorrect Virtual Servers
The following reply was made to PR config/2005; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Al Sutton \(Shatz Creations\) [EMAIL PROTECTED] Cc: Oliver von Bueren [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: config/2005: Incorrect Virtual Servers Date: Tue, 14 Apr 1998 11:16:15 -0700 (PDT) Without a sample config I can't debug any problem. That's why I asked for it. Dean On Tue, 14 Apr 1998, Al Sutton (Shatz Creations) wrote: The machine my problems occured on only has one IP address, and the DNS entries for all names are fine. As I stated before, 1.2.5 works fine, drop in the 1.2.6 binary and things break, drop back to the 1.2.5 binary and all is OK again. Al. Dean Gaudet wrote: On your webserver machine, try this: % telnet ntinternals.ovb.ch 80 % telnet ntinternals.mhs.ch 80 and make sure that it does get the same IP address for both -- maybe there's something wrong with the DNS on that server which is causing ntinternals.ovb.ch to have the wrong IP address. (I'm still looking for other possibilities.) Dean
Re: config/2005: Incorrect Virtual Servers
The following reply was made to PR config/2005; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Oliver von Bueren [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: config/2005: Incorrect Virtual Servers Date: Thu, 9 Apr 1998 13:23:35 -0700 (PDT) On your webserver machine, try this: % telnet ntinternals.ovb.ch 80 % telnet ntinternals.mhs.ch 80 and make sure that it does get the same IP address for both -- maybe there's something wrong with the DNS on that server which is causing ntinternals.ovb.ch to have the wrong IP address. (I'm still looking for other possibilities.) Dean
Re: config/2005: Incorrect Virtual Servers
The following reply was made to PR config/2005; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Oliver von Bueren [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: config/2005: Incorrect Virtual Servers Date: Thu, 9 Apr 1998 13:49:16 -0700 (PDT) On Thu, 9 Apr 1998, Oliver von Bueren wrote: hosts bind and in the hosts there was the wrong ip address entered. The address there was .144, which is the primary address for this machine (FreeBSD 2.1.7 by the way). The DNS has .145, which all the other mentioned vhost have too. Yup this is the bug then, it's a configuration problem... you'll need to fix that dns. (That's why I asked about it). (I'm still looking for other possibilities.) I still see it as a strange behavor in Apache 1.2.6 and definitly different that 1.2.5. It's definately different, it was deliberately changed for security reasons. Suppose that one of the addresses had been 10.0.0.1 and only supposed to be accessed via your local network, and not from the wild internet (i.e. filtered at your router). Apache prior to 1.2.6 (and prior to 1.3b1 I think it was) would happily let you access hosts that were bound to other IP addresses. Here's the CHANGES entry: *) SECURITY: When a client connects to a particular port/addr, and gives a Host: header ensure that the virtual host requested can actually be reached via that port/addr. [Ed Korthof [EMAIL PROTECTED]] The .144 is a valid address for this host and Apache does listen to that IP too. Another very strange this is, that if I make a request to the IP address itself, http://195.65.24.144, I don't end up at www.ovb.ch, but the default page for that IP address, which is not a virtual host but the global page as defined by ServerRoot outside any VirtualHost. So if Apache only checks VirtualHosts for .144, it shoud have returned the main documents for the server and not www.ovb.ch. I'd need more of the config to know if this is wrong. Usually you want to put in a _default_ virtual host to control access to otherwise unspecified IP addresses. It could just be one of the other brokennesses of pre 1.3 vhosts... and unlikely to be fixed (since it's all rewritten in 1.3 anyhow). Dean
Re: os-linux/2049: SIGSEGV attempting to dump core when serving pages
The following reply was made to PR os-linux/2049; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Mark Cantrell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-linux/2049: SIGSEGV attempting to dump core when serving pages Date: Wed, 8 Apr 1998 11:49:48 -0700 (PDT) I don't have any redhat 5.0 systems to test on because I don't trust them to be stable yet. The latest versions should work with apache, if they don't then it's likely a redhat or glibc bug. You may need to recompile apache... have you tried that? Dean
Re: os-sunos/2044: Fatal error: Command failed for target `alloc.o' during the make process
The following reply was made to PR os-sunos/2044; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Malcolm Nooning [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: os-sunos/2044: Fatal error: Command failed for target `alloc.o' during the make process Date: Tue, 7 Apr 1998 11:23:15 -0700 (PDT) If I had to take a wild guess, which I will, you've installed a gcc which doesn't match the header files on solaris 2.4. Maybe one built against 2.5, or maybe one built against a much earlier beta version of 2.4 (there was a gcc binary floating around like this for a long time). This isn't an apache bug, __builtin_va_list is gcc talking to itself, and if it doesn't have the definition somewhere then gcc is missing or has the wrong header files. Dean
Re: general/2031: logs incorrectly handled
The following reply was made to PR general/2031; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jon D. Marburger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], John Buswell [EMAIL PROTECTED] Subject: Re: general/2031: logs incorrectly handled Date: Tue, 7 Apr 1998 12:05:36 -0700 (PDT) On Tue, 7 Apr 1998, Jon D. Marburger wrote: Is NFS involved? Yes. The central nfs server contains a raid5 array which allows /home to be nfs-mounted on w3.one.net, shell.one.net, and other user servers. (httpd runs on w3.one.net, I was logged in on shell.one.net.) I do not know which version of nfsd each machine is running as it has been awhile since I administered them. This is the problem. NFS doesn't preserve unix filesystem semantics, especially regarding append files. You'll either need to log locally, or log via a network socket or something else to the server. You shouldn't be logging in user home directories anyhow, it's a security hazard... at least that's what I think you're doing. It's better to log into a central location on the webserver, and NFS export that. This is both secure and reliable. Users just can't rotate their logs... I mean sure you could code up something so they could, but we're not going to support it, it's far too much of a security problem. Dean
Re: config/2036: Appears to confuse DocumentRoot with ServerRoot
The following reply was made to PR config/2036; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Larry Breyer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: config/2036: Appears to confuse DocumentRoot with ServerRoot Date: Mon, 6 Apr 1998 10:27:59 -0700 (PDT) Did you enable any optimization when you compiled it with the sun compiler? Does it work if you disable optimization? Dean
Re: mod_include/2033: #set var does not pass the value onto any subsequent #include files
The following reply was made to PR mod_include/2033; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jim Kissel [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_include/2033: #set var does not pass the value onto any subsequent #include files Date: Mon, 6 Apr 1998 10:30:07 -0700 (PDT) This should be fixed in 1.3b5. But I see nobody has bothered to create a windows executable yet. Dean
Re: protocol/2032: When a POST or GET contains more than exactly 480 chars (CONTENT_LENGTH) improper headers SEEM to be sent
The following reply was made to PR protocol/2032; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: protocol/2032: When a POST or GET contains more than exactly 480 chars (CONTENT_LENGTH) improper headers SEEM to be sent Date: Mon, 6 Apr 1998 10:31:19 -0700 (PDT) Please upgrade to 1.2.6 and try again. Dean
Re: general/2031: logs incorrectly handled
The following reply was made to PR general/2031; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: Jon D Marburger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/2031: logs incorrectly handled Date: Mon, 6 Apr 1998 10:34:43 -0700 (PDT) On 3 Apr 1998, Jon D Marburger wrote: From userspace with a virtual domain in your home directory: rm error.log ; touch error.log; chmod 606 error.log Um, unless you're restarting the server while doing this then you've just deleted the error log and nothing else will be written. Apache dumps binary data to error.log for the virt dom to the last size of the file, then appends data normally. This sounds like there is an external program managing the error.log rather than apache. Are the error logs piped through a program? Is there any cgiwrap or similar pogram involved? Is NFS involved? Allow apache to write to log files without needing a hup, or edit source to enforce no-writes until a hup It is impossible to do this. Dean
Re: mod_include/2033: #set var does not pass the value onto any subsequent #include files (fwd)
The following reply was made to PR mod_include/2033; it has been noted by GNATS. From: Dean Gaudet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Subject: Re: mod_include/2033: #set var does not pass the value onto any subsequent #include files (fwd) Date: Mon, 6 Apr 1998 11:13:17 -0700 (PDT) -- Forwarded message -- From: Jim Kissel [EMAIL PROTECTED] Subject: Re: mod_include/2033: #set var does not pass the value onto any subsequent #include files To: Dean Gaudet [EMAIL PROTECTED] Date: Mon, 6 Apr 1998 19:05:12 + (GMT) It was a mistake on my part to report this bug. About 24 hours later, I realised what was wrong. The subsequent files were .html and not parsed. I'm a fool Once I realised this was the problem and changed the !--#include files to .shtml so they were parsed, the problem went away. Sorry for any inconvience caused /foolish off regards This should be fixed in 1.3b5. But I see nobody has bothered to create a windows executable yet. Dean
