Can't get makefile to work
After following the on-screen instructions to download, configure and make Flood I get the following error message when I run Make. Any ideas? [EMAIL PROTECTED] flood]$ make all Making all in apr make[1]: Entering directory `/home/bcharlton/flood/httpd-test/flood/apr' make[1]: *** No rule to make target `all'. Stop. make[1]: Leaving directory `/home/bcharlton/flood/httpd-test/flood/apr' make: *** [all-recursive] Error 1
Re: Can't get makefile to work
On Tue, Feb 12, 2002 at 01:18:43PM +, Brian Charlton wrote: After following the on-screen instructions to download, configure and make Flood I get the following error message when I run Make. Any ideas? [EMAIL PROTECTED] flood]$ make all Making all in apr make[1]: Entering directory `/home/bcharlton/flood/httpd-test/flood/apr' make[1]: *** No rule to make target `all'. Stop. make[1]: Leaving directory `/home/bcharlton/flood/httpd-test/flood/apr' make: *** [all-recursive] Error 1 For some reason the 'all' rule is picking up your apr subdirectory, and running 'cd apr; make all' in there. Move that directory out of the way and try again. BTW, you can just run 'make'. Where in the docs do you see 'make all'? -aaron
RE: mod_proxy hides X-Cache header from upstream server in 1.3.23
Ok, now I can see again which upstream server cached the requested object :-) The behaviour is almost that same it was before with the difference that in older versions I had one or more headers of type X-Cache, whereas now I have one X-Cache header with multiple value (ap_mergen_table instead of ap_addn_table). As far as I remember multiple headers are depreciated in favour of mulivalued headers, so its ok? Thanks a lot for the quick response and the patch, Jacob From: Graham Leggett [mailto:[EMAIL PROTECTED]] Apache was ap_table_set()'ing the header instead of ap_table_merge()'ing the header - which meant any previous upstream value was overwritten and lost. I have just committed a fix to the apache 1.3.24-dev tree. Can you check it out, give it a try and tell me if your problem is fixed? Regards, Jacob
2.0.31 include and expires
I've been playing with 2.0.31 and I've noticed something strange. All of our .html and .htm files are server-parsed and should also have an expire time set. Strange thing is, if I set something like: AddOutputFilter INCLUDES html htm ExpiresActive On ExpiresByType text/html A60 A request for http://foo/ does not get parsed or get expiry headers set. However, http://foo/index.hml works as expected. If I set: FilesMatch \.htm?l$ SetOutputFilter INCLUDES ExpiresActive On ExpiresDefault A60 /FilesMatch http://foo/ gets parsed, but no Expire Headers. Once Again, http://foo/index.hml gets parsed and headers get added. In order for http://foo/ to work correctly I use: FilesMatch \.htm?l$ SetOutputFilter INCLUDES ExpiresActive On ExpiresDefault A60 /FilesMatch LocationMatch /$ ExpiresActive On ExpiresDefault A60 /LocationMatch This just doesn't seem right, I have been toying with porting some of our modules to Apache 2, but I obviously don't understand what's going here. Why isn't http://foo/ recognized as text/html? -- Brian Akins Systems Engineer III CNN Internet Technologies
Re: 2.0.31 include and expires
This was a key reason for my mod_dir patch that broke Brian's request, below.
This is also a mod_negotiation bug, we simply hadn't realized it yet.
From: Brian Akins [EMAIL PROTECTED]
Sent: Tuesday, February 12, 2002 7:35 AM
I've been playing with 2.0.31 and I've noticed something strange. All of our
.html and .htm files are server-parsed and should also have an expire time
set. ...
A request for http://foo/ does not get parsed or get expiry headers set.
However, http://foo/index.hml works as expected.
This just doesn't seem right, I have been toying with porting some of our
modules to Apache 2, but I obviously don't understand what's going here. Why
isn't http://foo/ recognized as text/html?
No, it is not right, and yes - http://foo/ should be appropriately recognized.
We are evidently not moving enough info from the subreq to the parent request
in ap_fast_internal_redirect(); at least the filter chain, and some meta data
related to the expires date
Set{Input|Output}Filter[ByType] all set up filters in the typemap hook. It
appears we did not copy these from the internal DefaultIndex subrequest back
into the main request - we needed to. I'm not certain where the expires date
is cached; the output headers? In any case, perhaps the entire headers need to
slide from the sub request to the main request.
A better answer is possibly to drop ap_internal_fast_redirect altogether (and
changing both mod_dir and mod_negotiation to never use the beast again) - that
includes Apache 1.3. This code, while normalized, is not much better than
it was playing 1.3 negotiation. The code has been a source of vulnerabilities
which I fixed, and other 'bugs' - most of which I'd fixed. Who knows how many
more lurk, waiting to be 'discovered'.
Axe ap_internal_fast_redirect()? Are any 3rd party modules taking advantage
of this hack from negotiation?
Bill
Re: Random languages for httpd.apache.org/docs (fwd)
Adam, There was a code change related to a new httpd 2.0 config directive, ForceLanguagePriority, that caused the strange language behavior you noticed. It seems the new directive doesn't have an appropriate default setting. I have temporarily changed apache.org's config file to compensate, so you should see English once again when your browser doesn't have another language configured. Thanks for reporting this problem, and our apologies for any inconvenience. Greg Ames --- Brian Behlendorf wrote: Heh, anyone want to check this out? Brian -- Forwarded message -- Date: Sat, 9 Feb 2002 05:05:58 -0600 From: Adam Hupp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Random languages for httpd.apache.org/docs I get french for /docs, and german for /docs/mod/directives.html. -Adam
RE: new mod_proxy + multiple set-cookie
From: Graham Leggett [mailto:[EMAIL PROTECTED]] Joshua Slive wrote: Just a heads up: There are multiple bug reports that claim that the new mod_proxy is messing up when multiple set-cookie headers are present, which prevents some sites like hotmail from working correctly. Anyone who is interested should check the bug database. I have just committed a fix for this - can someone check that the cookie problem is fixed? I just closed a bunch of the bug reports with a note that asks them to check the patch (copied to http://www.apache.org/~slive/proxy-patch.txt ) Joshua.
Re: Solaris8 Problem with native compiler
jean-frederic clere [EMAIL PROTECTED] writes: I have some problems with the httpd-2.0 (from CVS). Whe compiled with Sun compiler it hangs at startup: +++ $c libc.so.1`_lwp_sema_wait+8(8d7f0, ff19e000, 0, 8d738, 2501c, 0) libthread.so.1`_swtch+0x400(8d738, 8d738, ff19e000, 5, 671, cf3c0) libthread.so.1`_mutex_adaptive_lock+0x144(ff1a9944, 6400, 4c00, 1, 4d58, fffe) libthread.so.1`_cmutex_lock+0x50(ff29e448, ff, ff280fce, ff21a82c, ffbef680, ff280fce) libnsl.so.1`_get_hostserv_inetnetdir_byname+0x224(ffbef78c, ffbef794, 0, ffbef794, ff29ae30, 93c09) libnsl.so.1`getipnodebyname+0x12c(0, 0, 8e6a8, ffbef80c, 93c08, cea38) libsocket.so.1`get_addr+0xc4(0, 93c08, ffbef980, 1, ff31a000, 1e62) libsocket.so.1`getaddrinfo+0x524(ff31ac0c, 93c08, 1e62, ffbefa1c, ff31a000, ffbef980) libapr.so.0`apr_sockaddr_info_get+0x14c(d7cc4, 93c08, 0, 1e62, 0, 95930) ap_mpm_pod_open+0xd8(95930, 8a66c, 49, 1, ff3e, ff370330) prefork_open_logs+0xb0(95930, bd9f8, bfa00, 975e0, bfa00, 0) ap_run_open_logs+0x98(95930, bd9f8, bfa00, 975e0, 0, 0) main+0x864(1, ffbefc9c, ffbefca4, 87800, 0, 0) _start+0xb8(0, 0, 0, 0, 0, 0) +++ I've finally verified that there is a Solaris fix for this. I think the specific patch is 109326 (Sparc) or 109327 (i386), but in truth I installed the current Solaris recommended patch cluster in its entirety (which included that patch). After patch installation and reboot, I didn't hit the problem again. (Funny: While you were encountering and reporting this and I was trying to think of what it might be, I had a regression test blocked for days and days in the same getaddrinfo() call on an unpatched Sun 8 box at the office. Unfortunately, the sendmail cfg on that box is hosed and I didn't see the error messages from it being hung.) Now that the box is working better I see a couple of errors that need further study: 1) cgi request handled by cgid right after a restart isn't working (I added a bunch of restarts in my regression test during the days that it was hung on Solaris, so probably this isn't related to the patchlevel) 2) POD issue with worker MPM: [Tue Feb 12 12:01:46 2002] [notice] SIGUSR1 received. Doing graceful restart [Tue Feb 12 12:01:46 2002] [warn] (128)Network is unreachable: connect to listener -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Mirroring Web Content
Apache Developers, Hello! I apologize if this has been discussed in this fashion many times, but I have attempted to read around and wasn't able to directly find any indication that it has been. Please flame me offlist for my naivite. == THE MIRRORING PROBLEM As a website's popularity grows, it becomes increasingly desirable to have mirrors of the website located in various places, in order to spread the processing and bandwidth expense of serving a page across many servers and to reduce the path length traversed by a packet going from server to client. The Apache Group itself uses mirrors, as do the Qmail and Postfix projects, the Linux Kernel site, and innumerable other popular websites. There are several ways to inform a client as to the availability of a file on alternate servers: 1) Click On It Yourself. This approach, the one used by most Open Source project pages, involves a clickable list of mirrors being presented in the HTML body; it is assumed that a kind user will find a mirror instead of downloading from the main site. Some sites, like http://qmail.org/, somewhat enforce this usage pattern by prompting for a location before a user can engage the site. Some, like Apache, use a dynamic list of mirrors to reduce the probability that some poor singular mirror that was listed first will get all the traffic. This approach is nicely centralized and is easy to administer, but is a pain for the user. Cookies to remember a user's preferred location might be useful in helping make localization a one-time effort and not a continuous one. This is also not a standards-based approach. Every website must go it on their own. Thankfully, this is not hard. 2) Use Clever DNS Servers This is somewhat the IRC-server approach, and moreso the approach that Akamai adopted. Most largescale commercial websites use clever DNS servers that can field a reasonable guess as to what webservers are likely to be closest to you and to return their IP addresses. This requires no client-side intelligence or user interaction. The seamless, scalable, and elegant nature of this approach has made it strongly compelling for the commercial web. I don't know what Open Source DNS software is capable of location-based IP issuance: I would love to hear of any. This approach is equally centralized but requires control over the DNS server, something that many small to midsized websites don't have. Getting a smarter DNS into ISPs that did proximity-based IP address returns wouldn't require even modifying MX records, and could be a real coup. But this approach also requires mirroring the site in its entirety. 3) Use HTTP Redirects This approach is not used nearly as often as the first two. A script could be written to redirect a web browser wanting to download a given file to a specific mirror where file resides. This has the advantage of not requiring all files to be on all mirrors, or even the same set of files on all mirrors. This does require writing some (simple) new software to manage the connection redistribution; this could be an Apache module. One of its actions could be to simply let the request be served by the local host until some certain bandwidth/CPU/memory threshold was crossed, at which point it could begin dishing out redirects to mirrors likely to be near the requestor. This approach is more powerful than the above two (it's seamless, but doesn't require mirroring the whole site). It would work best as an Apache module, which would require control over the web server being used to service requests, but a user could theoretically change their entire site to be served by a CGI that could perform that same function. This would probably require changing the site's layout and would involve a great deal of work on their part. 4) Use HTTP Headers The next approach is to use two new fields in the HTTP response to a HEAD request: X-Mirrored-By and X-MD5. A sample HTTP request/response: [client] HEAD /very/big.movie HTTP/1.1 [client] Host: MovieServer.com [client] [server] HTTP/1.1 200 OK [server] Content-Length: 205392839 [server] Content-Type: movie/quicktime [server] X-Mirrored-By: http://mirror.in.co.uk/movserv/the.movie [server] X-Mirrored-By: http://downunder.com.au/mirrors/ms/funny.mov [server] X-Mirrored-By: http://friend.in.co.tw/movies/big.movie [server] X-MD5: 5FD298A9782394C2 This would enable the client to find the mirror closest to it and possibly even download the file simultaneously from multiple locations. The MD5 checksum and content length would ensure that the end result was correct, something that the other methods above don't provide. This approach has not yet been implemented; I would like to bring it up for discussion with you, the Apache developers. It could be used today with setups that allow websites to control their own headers. I've reviewed the HTTP 305
modules.apache.org
This has historically been a Covalent hosted and driven project, as a service to the Apache community. Covalent has decided to open that project up to the community to improve. To that end, sometime next week, I will be setting up a machine as a web server and CVS server to be used for modules.apache.org. That machine will be hosted by Covalent, and accounts on that machine will be given out as it makes sense. For the time being, I will be admin'ing the machine in my spare time, so things may take a while to get kick-started. The reason I am sending this message is because I have been asked about this project every few weeks for the last year or so. I wanted to let everybody know that we are making progress and this project will be available to hack on in about a week or two. Please be patient. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA
Re: modules.apache.org
Ryan Bloom wrote: That machine will be hosted by Covalent, and accounts on that machine will be given out as it makes sense. For the time being, I will be admin'ing the machine in my spare time, so things may take a while to get kick-started. Please colour me interested in helping.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Interesting Apache 2.0 project...
I've wanted to look into this for quite awhile but never seem to have the time to do it... Wouldn't it be cool if the interface between the server and mod_cgi (or any other content generator) could be configured to be full duplex (rather than stuck at half duplex as it is today)? With any version of Apache, it is not possible to support an HTTP transaction that consists of a continuous stream of chunked encoded bytes from the client and a concurrent stream of chunk encoded bytes back to the server because the interface between the server and the application (a cgi script for example) is half-duplex. The server will not attempt to read any bytes from the application until it has received ALL of the request. The cgi must read and buffer ALL of the request before sending any of the response else the application risks deadlocking with the server. This is an interesting exercise in that we will need manipulate the blocking behaviour of the network layer from the top of the filter stack. Bill
Re: modules.apache.org
On Tue, Feb 12, 2002 at 02:30:28PM -0500, Rodent of Unusual Size wrote: Ryan Bloom wrote: That machine will be hosted by Covalent, and accounts on that machine will be given out as it makes sense. For the time being, I will be admin'ing the machine in my spare time, so things may take a while to get kick-started. Please colour me interested in helping.. Are there any projects regarding modules.apache.org that will require development effort? I'd be interested in helping if that is the case. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
RE: modules.apache.org
The hope is that we will replace the entire look and feel of the modules.apache.org site. I am hoping that once I have the machine up and running, I can create a mailing list, and we can all discuss our goals for the site at that time. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: Thomas Eibner [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 11:44 AM To: [EMAIL PROTECTED] Subject: Re: modules.apache.org On Tue, Feb 12, 2002 at 02:30:28PM -0500, Rodent of Unusual Size wrote: Ryan Bloom wrote: That machine will be hosted by Covalent, and accounts on that machine will be given out as it makes sense. For the time being, I will be admin'ing the machine in my spare time, so things may take a while to get kick-started. Please colour me interested in helping.. Are there any projects regarding modules.apache.org that will require development effort? I'd be interested in helping if that is the case. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
Re: Patch for PR# 4634
Nice. On Sun, 10 Feb 2002, Dave Dribin wrote: Hi, I've attached a patch against 1.3.23 that modifies ./configure to take a --force-suffix option as a solution to PR# 4634. http://bugs.apache.org/index.cgi/full/4634 This keeps the default behavior as is, but allows people who want to have the additional httpd tacked on the directories to do so, even if it is already in an apache subdirectory. BTW, for those wondering why this would be useful, I use epkg to install Apache as an encap package. http://www.encap.org/epkg/ The extra httpd subdirectories become useful when epkg makes symlinks to the encap directory, such as: /usr/local/etc/httpd/httpd.conf - ../../encap/apache-1.3.23/etc/httpd/httpd.conf I'd rather keep the files in /usr/local/etc/httpd rather than /usr/local/etc. -Dave
UseCanonicalName Off in default config
Any objection to the following default config change (for 2.0 only)? This configuration seems more idiot-proof and would eliminate a huge chunk of newbie why can't I access a directory without a trailing slash questions. I'm posting here before committing because I don't know if there may be some subtle security or other issue that has prevented this change from being made long ago. Joshua. Index: httpd-std.conf === RCS file: /home/cvs/httpd-2.0/docs/conf/httpd-std.conf,v retrieving revision 1.79 diff -u -d -b -r1.79 httpd-std.conf --- httpd-std.conf 25 Jan 2002 00:24:47 - 1.79 +++ httpd-std.conf 12 Feb 2002 20:07:55 - @@ -384,14 +384,13 @@ /Files # -# UseCanonicalName: With this setting turned on, whenever Apache needs -# to construct a self-referencing URL (a URL that refers back to the -# server the response is coming from) it will use ServerName to form -# a canonical name. With this setting off, Apache will use the -# hostname:port that the client supplied, when possible. This also -# affects SERVER_NAME and SERVER_PORT in CGI scripts. +# UseCanonicalName: Determines how Apache constructs self-referencing +# URLs and the SERVER_NAME and SERVER_PORT variables. +# When set Off, Apache will use the Hostname and Port supplied +# by the client. When set On, Apache will use the value of the +# ServerName directive. # -UseCanonicalName On +UseCanonicalName Off # # TypesConfig describes where the mime.types file (or equivalent) is
RE: cvs commit: httpd-2.0/modules/experimental mod_mem_cache.c
Doesn't the race condition still exist? For example, I can delete the
object after the if but before the hash_set. You need a mutex, don't
you?
Ryan
-apr_hash_set(sconf-cacheht, obj-key, strlen(obj-key), NULL);
+/*
+ * RACE .. some one might have just deleted this object .. so
test
+ * if it is still around
+ */
+if (obj) {
+apr_hash_set(sconf-cacheht, obj-key, strlen(obj-key),
NULL);
+cleanup_cache_object(obj);
+h-cache_obj = NULL;
+}
if (sconf-lock) {
apr_thread_mutex_unlock(sconf-lock);
-}
-
-cleanup_cache_object(obj);
+}
return OK;
}
Re: cvs commit: httpd-2.0/modules/experimental mod_mem_cache.c
oops.. used the wrong email from address to reply.
there is a mutex around this code.
what I changed was to add the cleanup_cache_object into the mutex lock
Ryan Bloom wrote:
Doesn't the race condition still exist? For example, I can delete the
object after the if but before the hash_set. You need a mutex, don't
you?
Ryan
-apr_hash_set(sconf-cacheht, obj-key, strlen(obj-key), NULL);
+/*
+ * RACE .. some one might have just deleted this object .. so
test
+ * if it is still around
+ */
+if (obj) {
+apr_hash_set(sconf-cacheht, obj-key, strlen(obj-key),
NULL);
+cleanup_cache_object(obj);
+h-cache_obj = NULL;
+}
if (sconf-lock) {
apr_thread_mutex_unlock(sconf-lock);
-}
-
-cleanup_cache_object(obj);
+}
return OK;
}
Re: UseCanonicalName Off in default config
On Tue, Feb 12, 2002 at 03:11:52PM -0500, Joshua Slive wrote: This configuration seems more idiot-proof and would eliminate a huge chunk of newbie why can't I access a directory without a trailing slash questions. I'm posting here before committing because I don't know if there may be some subtle security or other issue that has prevented this change from being made long ago. Typically, you expect people to _at_least_ be able to configure their own host name correctly. Alas, even some vendors supply a default configuration with ServerName localhost or ServerName 127.0.0.1. For these, the change is the best fix. For the former (and for everyone who _knows_ what he's doing), the old logic whatever you typed in to reach me, I use my correct name nonetheless is probably better. +0.5 from here for the change. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: modules.apache.org
On Tue, Feb 12, 2002 at 11:48:10AM -0800, Ryan Bloom wrote: The hope is that we will replace the entire look and feel of the modules.apache.org site. I am hoping that once I have the machine up and running, I can create a mailing list, and we can all discuss our goals for the site at that time. Hopefully it will be better connected (at least for european users, the current modules.apache.org is dead slow and unreliable). Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: Interesting Apache 2.0 project...
On Tue, Feb 12, 2002 at 02:25:40PM -0500, Bill Stoddard wrote: This is an interesting exercise in that we will need manipulate the blocking behaviour of the network layer from the top of the filter stack. Indeed -- but then it's no longer CGI (different interface), so you lose all the CGI applications. There has already been fcgi (in an attempt at providing almost source level compatibility, and winning speed by recycling processes instead of forking all the while). Also, RFC2388 might be interesting to implement some day... Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: modules.apache.org
On Tue, Feb 12, 2002 at 11:41:20PM +0100, Martin Kraemer wrote: On Tue, Feb 12, 2002 at 11:48:10AM -0800, Ryan Bloom wrote: The hope is that we will replace the entire look and feel of the modules.apache.org site. I am hoping that once I have the machine up and running, I can create a mailing list, and we can all discuss our goals for the site at that time. Hopefully it will be better connected (at least for european users, the current modules.apache.org is dead slow and unreliable). Funny. I never had any problems accessing it from Denmark. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
Re: modules.apache.org
Hopefully it will be better connected (at least for european users, the current modules.apache.org is dead slow and unreliable). Can you send me a traceroute from where you are? I can't promise that I can do anything with it, but it'll be interesting to know where the packets flow when they are so slow. S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 536 5214 645 Howard St. Fax: (415) 536 5210 San Francisco CA 94105 PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message ===
Re: cvs commit: httpd-2.0/server/mpm/winnt service.c
wrowe 02/02/12 19:33:34 Modified:server/mpm/winnt service.c Log: The final commit to achieve a quality release. We cannot use CreateThread on Win32 when using the clib; msvcrt has its own initialization and destruction, so it needs its own turn. _createthreadex is the same but different - it's implemented by msvcrt and causes all the appropriate setup and teardown to occur. Revision ChangesPath 1.44 +5 -5 httpd-2.0/server/mpm/winnt/service.c Looks like that was the last semi-critical bit. We have liftoff on Win32 again :) Bill
Re: cvs commit: httpd-2.0 STATUS
I should have both of these done in the next 24 hours, but in case someone's itching to roll a release tarball now that the Win32 bugs have been squashed I wanted to let it be known that I won't support a beta from current CVS. But don't let me hold up the show. I won't be changing critical interfaces with either of these issues, I just think they are critical annoyances. :) -aaron On Wed, Feb 13, 2002 at 06:09:03AM -, [EMAIL PROTECTED] wrote: aaron 02/02/12 22:09:02 Modified:.STATUS Log: Just a heads up to let people know what I'm working on. I ran into some problems with the new POD code in the worker MPM, and although I'm almost finished I didn't want people rolling a tarball without knowing of these problems first. Revision ChangesPath 1.499 +15 -1 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.498 retrieving revision 1.499 diff -u -r1.498 -r1.499 --- STATUS 13 Feb 2002 04:49:55 - 1.498 +++ STATUS 13 Feb 2002 06:09:02 - 1.499 @@ -1,5 +1,5 @@ APACHE 2.0 STATUS: -*-text-*- -Last modified at [$Date: 2002/02/13 04:49:55 $] +Last modified at [$Date: 2002/02/13 06:09:02 $] Release: @@ -110,6 +110,12 @@ but is hesitant to do the same for the httpd binary. Message-ID: [EMAIL PROTECTED] +* [Aaron] All signals have been removed from the worker MPM, which + makes the code significantly cleaner, but there are a couple of + lingering problems: +* mod_cgid doesn't die at shutdown +* httpd -X and -DONE_PROCESS is broken +Status: Aaron volunteers. (This is a -1 for beta from him) CURRENT VOTES: @@ -139,6 +145,14 @@ -0: Aaron (premature decision, needs more discussion), Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: + +* When we start httpd with the -DNO_DETACH flag on Unix, we + should still create a new session (and possibly also still close + stdin/stdout/stderr and redirect from /dev/null), so that + process management tools like 'daemontools' or AIX's System + Resource Controller can manage apache. +Message-ID: [EMAIL PROTECTED] +Status: Aaron volunteers. * Usage of APR_BRIGADE_NORMALIZE in core_input_filter should be removed if possible.
Re: cvs commit: httpd-2.0 STATUS
On Wed, Feb 13, 2002 at 06:09:03AM -, [EMAIL PROTECTED] wrote: aaron 02/02/12 22:09:02 Modified:.STATUS Log: Just a heads up to let people know what I'm working on. I ran into some problems with the new POD code in the worker MPM, and although I'm almost finished I didn't want people rolling a tarball without knowing of these problems first. FWIW, my JRE_1 tag does *not* have this change. rbb and I agreed that it wasn't necessary to have the signal-less worker MPM in any beta as it doesn't affect modules. It also gives time to stablize problems like these. If OtherBill can provide me a list of changes to Win32 that are needed for any .32 beta, I can bump those files and roll JRE_1. OtherBill? -- justin
