[STATUS] (httpd-2.1) Wed Sep 17 23:45:28 EDT 2003
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2003/08/31 16:14:38 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.0 : in development Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * just do an egrep on "TODO" or "XXX" and see what's there CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2 * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2 CURRENT VOTES: * Promote mod_cache from experimental to non-experimental status (keep issues noted below in EXPERIMENTAL MODULES as items to be addressed as a supported module). +1: jim, bnicholes -0: jerenkrantz -1: stoddard There are a couple of problems that need to be resolved before this module is moved out of experimental. 1) We need to at least review and comment on the RFC violations 2) Resolve issue of how to cache page fragements (or perhaps -if- we want to cache page fragements). Today, mod_cache/mod_mem_cache will cache #include 'virtual' requests (but not #include 'file' requests). This was accomplished by making CACHE_IN a CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE filter. But now responses cannot be cached that include the effects of having been run through CONTENT_SET filters (mod_deflate, mod_expires, etc). We could rerun all the CONTENT_SET filters on the cached response, but this will not work in all cases. For example, mod_expires relies on installing the EXPIRATION filter during fixups. Contents served out of mod_cache (out of the quick_handler) bypass -all- the request line server hooks (Ryan really hated this. It is great for performance, but bad because of the complications listed above). jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla for mod_cache (see 'RFC 2616 violations' below). I think fixing them is a pre-requisite before it isn't experimental. * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes "gracefully" self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a "hot spare"). See: Message-ID: <[EMAIL PROTECTED]> Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Filter stacks and subrequests, redirects and fast redirects. There's at least one PR that suffers from the current unclean behaviour (which lets the server send garbage): PR 17629 nd says: Every subreque
[STATUS] (httpd-2.0) Wed Sep 17 23:45:19 EDT 2003
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2003/09/17 10:53:32 $] Release: 2.0.48 : in development 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * just do an egrep on "TODO", "XXX" and see what's there RELEASE SHOWSTOPPERS: PATCHES TO PORT FROM 2.1 [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] * The cache code should be able to cache a response if it has an Expires header but no Etag or Last-Modified headers. This submitted patch (by [EMAIL PROTECTED]) resolves PR 23130. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/mod_cache.c.diff?r1=1.76&r2=1.77 +1: rederpj, fielding, brianp * Modifies the cache code to be header-location agnostic. Also fixes a number of other cache code bugs related to PR 15852 (an RFC 2616 violation). http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/cache_storage.c.diff?r1=1.28&r2=1.29 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/cache_storage.c.diff?r1=1.29&r2=1.30 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/cache_util.c.diff?r1=1.27&r2=1.28 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/mod_cache.c.diff?r1=1.74&r2=1.75 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/mod_cache.c.diff?r1=1.75&r2=1.76 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/mod_cache.h.diff?r1=1.39&r2=1.40 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/mod_disk_cache.c.diff?r1=1.46&r2=1.47 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/mod_mem_cache.c.diff?r1=1.93&r2=1.94 +1: rederpj, fielding, trawick * Correct the code in ap_check_cache_feshness to check max_age, smax_age, and expires correctly. This is a RFC 2616 compliance issue. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/cache_util.c.diff?r1=1.26&r2=1.27 +1: rederpj, stoddard, fielding * mod_rewrite.c: Fix mod_rewrite's support of the [P] option to send rewritten request using "proxy:". The code was adding multiple "proxy:" fields in the rewritten URI. PR: 13946. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.153&r2=1.154 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.154&r2=1.155 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.156&r2=1.157 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.173&r2=1.174 +1: rederpj, nd, trawick, fielding * Replace some of the mutex locking in the worker MPM with atomic operations for higher concurrency. server/mpm/worker/fdqueue.c 1.24, 1.25 +1: brianp * Rewrite how proxy sends its request to allow input bodies to
[STATUS] (apache-1.3) Wed Sep 17 23:45:13 EDT 2003
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2003/09/02 20:10:36 $] Release: 1.3.29-dev: In development 1.3.28: Tagged July 16, 2003. 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the "first minutes" due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at "last minute" due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: None RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Current vote on 3 PRs for inclusion: Bugz #17877 (passing chunked encoding thru proxy) (still checking if RFC compliant... vote is on the correctness of the patch code only). +1: jim, chuck, minfrin Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message <[EMAIL PROTECTED]>) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: <[EMAIL PROTECTED]> Status: * Dean's "unescaping hell" (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: <[EMAIL PROTECTED]> Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-"server" pointer when being dereferenced by invoking "httpd -S". Message-ID: <[EMAIL PROTECTED]> Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: <[EMAIL PROTECTED]> Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker <[EMAIL PROTECTED]> to more fully close some segfault potential. Message-ID: <[EMAIL PROTECTED]> Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: <[EMAIL PROTECTED]> Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: <[EMAIL PROTECTED]> Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested)
Reviewers wanted for second edition of Apache Pocket Reference
I am hoping to get a second edition of the Apache Pocket Reference together for O'Reilly by the end of November and wondered whether anyone out there would like to act as technical reviewer for the new edition? (This edition will of course cover Apache version 2 as well as 1.3.) I would also welcome any comments based on the first edition of the book, especially pertaining to re-organization of the content.. Please reply by email directly to me. Andrew -- Andrew Ford, Director Ford & Mason Ltd / Pauntley Press [EMAIL PROTECTED] South Wing Compton House ford-mason.co.uk Compton Green, Redmarley Tel: +44 1531 829900 pauntley-press.co.uk Gloucester, GL19 3JB Fax: +44 1531 829901 refcards.com Great Britain Mobile: +44 7785 258278
Input filter and setting HTTP headers in Apache 2.0
Hi, I am writing a module need to be able to examine POST data, and insert inbound HTTP request headers after my code has been run by apache so that: 1. the web application can still retrieve the POST data if required for its own consumption 2. the web application needs to have access to the HTTP inbound request headers generated at runtime (mod_header can't help me) by my code. A web application in this case could be one of the following (not exhaustive): * a native apache 2.0 module * mod_jk with Tomcat on the back end actually running the application * mod_cgi/mod_cgid * mod_proxy (the back web webserver will act as the web application) Attempted Solution Use an input filter. This provides the mechanism to examine the POST data at my will without consuming it off the socket, thus giving the web application still the opportunity to consume it. The input filter chain happens during the handler phase, and is triggered if either of the following is true: 1. there is an explicit call by the web application to read the POST data (either calling the ap_XXX_client_block() series API or ap_get_brigade()) 2. in the case where the web application doesn't care about the POST data (but still requires the inbound HTTP request headers that my code creates), it is the ap_finalize_request_protocol() that triggers the input filter chain. This is most likely a special case, since if the web application doesn't care about the POST data, a GET would be more appropriate. Problem Let's say that the web application, before executing its own logic, needs to check for a HTTP request header that I generate to decide if it should proceed or not. So unless the web application tries to consume the POST data, my code (in the input filter) will never get the chance to run to insert those inbound HTTP request headers that the application requires. Question Is there a work around for the above solution in order to avoid the above problem, in order: 1. for my code to be able to examine the POST data and still allow the web application to consume it, and 2. for my code to be able to insert those inbound HTTP request headers so that the web application can see them at run time, without putting the constraint on it to have to retrieve the POST data first to have access to those inbound HTTP request headers? An example would be a cgi application that relies on mod_cgi. mod_cgi first reads the HTTP request headers before reading the POST data (add_common_vars() is called way before ap_get_brigade() in cgi_handler()). So that means the cgi application will never get the chance to see the headers that my code inserted. Once ap_get_brigade() returns, the headers will be set, but add_common_vars() has already been executed. Since I need to be able to peek at the POST data without consuming it, the input filter is the only known solution (right?).Is there a known work around this? The only way I can see where I will have the ability to insert those HTTP inbound request headers is if my filter runs between the CORE_IN and the HTTP_IN input filter, in which case I will need a properly populated request_rec* structure to be able to use the ap_XXX APIs (typical things would be get the mime-type, content-length of the POST data, protocol version, etc). Since my filter will run before the HTTP_IN filter would have had a chance to parse the request line and the request headers, it will most likely cause confusion within the Apache internal state. Any other ideas? Thanks, -Alberto
Re: cvs commit: apache-1.3/src/main rfc1413.c
No problem. How's this?
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> [EMAIL PROTECTED] Wednesday, September 17, 2003 1:18:49 PM >>>
If you will change the logic for multithreads (not to be confused with
your logic changes for winsock :-) from
#if (defined(NETWARE) || defined(WIN32))
to use
#ifdef MULTITHREAD
and decorate STATIC (e.g. RFC_USER_STATIC) to avoid possible name
clashes - I'd be very happy to accept this patch :-)
At 02:07 PM 9/17/2003, Brad Nicholes wrote:
> Sorry about the ugly .diff file. Forgot to add the -u when I did
the
>diff. I already caught the trashed stack variable and made the fix
so
>everything looks much better in the log (real info instead of trash).
I
>also believe that Apache is smart enough not to make the call on a
>keep-alive. In my testing I have seen a single request to the identd
>daemon but several entries for the page and .gifs in the access_log
with
>the correct information. Here is a good diff with the ap_pstrdup()
>added. If it looks good to you, I will go ahead and check it in.
>
>Brad
>
>Brad Nicholes
>Senior Software Engineer
>Novell, Inc., the leading provider of Net business solutions
>http://www.novell.com
>
[EMAIL PROTECTED] Wednesday, September 17, 2003 12:33:30 PM >>>
>At 01:09 PM 9/17/2003, Brad Nicholes wrote:
>>Ah yeah, I noticed the problem with the JMP_BUF but for some reason
I
>>missed the local statics. I am assuming that these local variables
>are
>>static simply to accomodate the setjmp() call. If I get rid of
>setjmp()
>>and simply set the recv/send timeouts on the socket itself, there
>>shouldn't be any reason to have the locals declared as static.
>>
>>See the attached .diff file. Seems to work fine on NetWare.
>
>First - e not diff -u and no file reference in the .diff :-?
>
>One more critical observation, if no longer static - this becomes
>evil:
>
>> #if (defined(NETWARE) || defined(WIN32))
>> if (setsocktimeout(sock, ap_rfc1413_timeout) == 0) {
>> if (get_rfc1413(sock, &conn->local_addr,
&conn->remote_addr,
>user, srv) >= 0)
>> result = user;
>
>result points to stack - promptly trashed. We will need to allocate
>char* user from a pool, although I suggest we keep the fixed length
>buffer
>and simply pstrdup into conn->pool after invoking rfc1413.
>
>Do we in 1.3 already protect against invoking this multiple times for
>a keep-alive connection? We should if we don't - it's expensive.
>
>Bill
>
>
rfc1413.c.diff
Description: Binary data
Re: cvs commit: apache-1.3/src/main rfc1413.c
If you will change the logic for multithreads (not to be confused with
your logic changes for winsock :-) from
#if (defined(NETWARE) || defined(WIN32))
to use
#ifdef MULTITHREAD
and decorate STATIC (e.g. RFC_USER_STATIC) to avoid possible name
clashes - I'd be very happy to accept this patch :-)
At 02:07 PM 9/17/2003, Brad Nicholes wrote:
> Sorry about the ugly .diff file. Forgot to add the -u when I did the
>diff. I already caught the trashed stack variable and made the fix so
>everything looks much better in the log (real info instead of trash). I
>also believe that Apache is smart enough not to make the call on a
>keep-alive. In my testing I have seen a single request to the identd
>daemon but several entries for the page and .gifs in the access_log with
>the correct information. Here is a good diff with the ap_pstrdup()
>added. If it looks good to you, I will go ahead and check it in.
>
>Brad
>
>Brad Nicholes
>Senior Software Engineer
>Novell, Inc., the leading provider of Net business solutions
>http://www.novell.com
>
[EMAIL PROTECTED] Wednesday, September 17, 2003 12:33:30 PM >>>
>At 01:09 PM 9/17/2003, Brad Nicholes wrote:
>>Ah yeah, I noticed the problem with the JMP_BUF but for some reason I
>>missed the local statics. I am assuming that these local variables
>are
>>static simply to accomodate the setjmp() call. If I get rid of
>setjmp()
>>and simply set the recv/send timeouts on the socket itself, there
>>shouldn't be any reason to have the locals declared as static.
>>
>>See the attached .diff file. Seems to work fine on NetWare.
>
>First - e not diff -u and no file reference in the .diff :-?
>
>One more critical observation, if no longer static - this becomes
>evil:
>
>> #if (defined(NETWARE) || defined(WIN32))
>> if (setsocktimeout(sock, ap_rfc1413_timeout) == 0) {
>> if (get_rfc1413(sock, &conn->local_addr, &conn->remote_addr,
>user, srv) >= 0)
>> result = user;
>
>result points to stack - promptly trashed. We will need to allocate
>char* user from a pool, although I suggest we keep the fixed length
>buffer
>and simply pstrdup into conn->pool after invoking rfc1413.
>
>Do we in 1.3 already protect against invoking this multiple times for
>a keep-alive connection? We should if we don't - it's expensive.
>
>Bill
>
>
Re: Sync to CVS problem
On Wed, 17 Sep 2003, Juan Rivera wrote: > I have previously downloaded a copy of the Apache server code from the cvs > repository using "anoncvs" login and > CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic. > > However, I am unable to connect to the server for the past couple of days. I > get the following error: > (Logging in to [EMAIL PROTECTED]) > CVS password: > cvs [login aborted]: recv() from server cvs.apache.org: EOF I just tried this and it worked fine for me. If you do an nslookup on cvs.apache.org, what address do you get? > Also, if I use the other server (CVSROOT= > :pserver:[EMAIL PROTECTED]:/cvs/apache) I can connect to the server. > However I cannot export the code using the command "cvs export -d httpd-2.0 > -r APACHE_2_0_44 httpd-2.0". I get the following error: > cvs export: cannot open /root/.cvsignore: Permission denied > cvs export: warning: cannot write to history file > /cvs/apache/CVSROOT/history: Permission denied > cvs export: Updating httpd-2.0 > cvs export: failed to create lock directory for `/cvs/apache/httpd-2.0' > (/cvs/apache/httpd-2.0/#cvs.lock): Permission denied > cvs export: failed to obtain dir lock in repository `/cvs/apache/httpd-2.0' > cvs [export aborted]: read lock failed - giving up I don't know anything about sourcery.org, can't help you there. --Cliff
Sync to CVS problem
Title: Sync to CVS problem Hi, I have previously downloaded a copy of the Apache server code from the cvs repository using "anoncvs" login and CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic. However, I am unable to connect to the server for the past couple of days. I get the following error: (Logging in to [EMAIL PROTECTED]) CVS password: cvs [login aborted]: recv() from server cvs.apache.org: EOF Also, if I use the other server (CVSROOT= :pserver:[EMAIL PROTECTED]:/cvs/apache) I can connect to the server. However I cannot export the code using the command "cvs export -d httpd-2.0 -r APACHE_2_0_44 httpd-2.0". I get the following error: cvs export: cannot open /root/.cvsignore: Permission denied cvs export: warning: cannot write to history file /cvs/apache/CVSROOT/history: Permission denied cvs export: Updating httpd-2.0 cvs export: failed to create lock directory for `/cvs/apache/httpd-2.0' (/cvs/apache/httpd-2.0/#cvs.lock): Permission denied cvs export: failed to obtain dir lock in repository `/cvs/apache/httpd-2.0' cvs [export aborted]: read lock failed - giving up Any ideas what may be wrong? Thanks Juan
Re: cvs commit: apache-1.3/src/main rfc1413.c
Sorry about the ugly .diff file. Forgot to add the -u when I did the
diff. I already caught the trashed stack variable and made the fix so
everything looks much better in the log (real info instead of trash). I
also believe that Apache is smart enough not to make the call on a
keep-alive. In my testing I have seen a single request to the identd
daemon but several entries for the page and .gifs in the access_log with
the correct information. Here is a good diff with the ap_pstrdup()
added. If it looks good to you, I will go ahead and check it in.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> [EMAIL PROTECTED] Wednesday, September 17, 2003 12:33:30 PM >>>
At 01:09 PM 9/17/2003, Brad Nicholes wrote:
>Ah yeah, I noticed the problem with the JMP_BUF but for some reason I
>missed the local statics. I am assuming that these local variables
are
>static simply to accomodate the setjmp() call. If I get rid of
setjmp()
>and simply set the recv/send timeouts on the socket itself, there
>shouldn't be any reason to have the locals declared as static.
>
>See the attached .diff file. Seems to work fine on NetWare.
First - e not diff -u and no file reference in the .diff :-?
One more critical observation, if no longer static - this becomes
evil:
> #if (defined(NETWARE) || defined(WIN32))
> if (setsocktimeout(sock, ap_rfc1413_timeout) == 0) {
> if (get_rfc1413(sock, &conn->local_addr, &conn->remote_addr,
user, srv) >= 0)
> result = user;
result points to stack - promptly trashed. We will need to allocate
char* user from a pool, although I suggest we keep the fixed length
buffer
and simply pstrdup into conn->pool after invoking rfc1413.
Do we in 1.3 already protect against invoking this multiple times for
a keep-alive connection? We should if we don't - it's expensive.
Bill
rfc1413.c.diff
Description: Binary data
Re: cvs commit: apache-1.3/src/main rfc1413.c
At 01:09 PM 9/17/2003, Brad Nicholes wrote:
>Ah yeah, I noticed the problem with the JMP_BUF but for some reason I
>missed the local statics. I am assuming that these local variables are
>static simply to accomodate the setjmp() call. If I get rid of setjmp()
>and simply set the recv/send timeouts on the socket itself, there
>shouldn't be any reason to have the locals declared as static.
>
>See the attached .diff file. Seems to work fine on NetWare.
First - e not diff -u and no file reference in the .diff :-?
One more critical observation, if no longer static - this becomes evil:
> #if (defined(NETWARE) || defined(WIN32))
> if (setsocktimeout(sock, ap_rfc1413_timeout) == 0) {
> if (get_rfc1413(sock, &conn->local_addr, &conn->remote_addr, user, srv) >= 0)
> result = user;
result points to stack - promptly trashed. We will need to allocate
char* user from a pool, although I suggest we keep the fixed length buffer
and simply pstrdup into conn->pool after invoking rfc1413.
Do we in 1.3 already protect against invoking this multiple times for
a keep-alive connection? We should if we don't - it's expensive.
Bill
Re: cvs commit: apache-1.3/src/main rfc1413.c
Ah yeah, I noticed the problem with the JMP_BUF but for some reason I
missed the local statics. I am assuming that these local variables are
static simply to accomodate the setjmp() call. If I get rid of setjmp()
and simply set the recv/send timeouts on the socket itself, there
shouldn't be any reason to have the locals declared as static.
See the attached .diff file. Seems to work fine on NetWare.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> [EMAIL PROTECTED] Wednesday, September 17, 2003 11:38:16 AM >>>
At 04:54 PM 9/16/2003, Brad Nicholes wrote:
> Looking through the code I don't see anything that would be a
thread-safety issue. What am I missing?
/* rfc1413 - return remote user name, given socket structures */
API_EXPORT(char *) ap_rfc1413(conn_rec *conn, server_rec *srv)
{
static char user[RFC1413_USERLEN + 1]; /* XXX */
static char *result;
static int sock;
Presumes that the requests are serialized (note static storage of
these
and the JMP_BUF, which might have per-thread context on some
platforms.)
Bill
rfc1413.c.diff
Description: Binary data
Re: cvs commit: apache-1.3/src/main rfc1413.c
At 04:54 PM 9/16/2003, Brad Nicholes wrote:
> Looking through the code I don't see anything that would be a thread-safety issue.
> What am I missing?
/* rfc1413 - return remote user name, given socket structures */
API_EXPORT(char *) ap_rfc1413(conn_rec *conn, server_rec *srv)
{
static char user[RFC1413_USERLEN + 1]; /* XXX */
static char *result;
static int sock;
Presumes that the requests are serialized (note static storage of these
and the JMP_BUF, which might have per-thread context on some platforms.)
Bill
RE: Tagged 2.0
> From: Jeff Trawick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 2:15 PM > Sander Striker wrote: > > > I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've > > put some tarballs containing that tag up at: > > There are some other fixes merged back since then, and it looks like > another set of fixes that are close to being approved. > > Here is one issue I'd strongly suggest resolving for 2.0.48: > > Greg indicated in the last couple of days that www.apache.org had almost > 12000 error messages (at that point) related to mutex errors with > mod_rewrite. That affects flock users (e.g., FreeBSD) starting the > server as root. I would suggest picking up this change to resolve that: *nod* That'd be a good one to include. > Beyond this one, I'm afraid that I'm not very familiar with the > real-world implications of not picking up the other available fixes. Everything that was voted upon can go in IMO. I was kind of hoping that we could get this release out this week, but I'm afraid that's not going to happen, if we want pre3 to serve on minotaur for a few days. > I'd like to think that within a couple of days we could get 7 or 8 more > fixes merged back, at which point we'd be ready for another release > anyway. But it wouldn't be prudent to count on that happening ;) Tell you what, if I see those merges start trickling in, I'll hold the pre3 tag til friday. We'll put the thing on minotaur directly, and announce to stable-testers. I'm hoping we can get enough +1s around tuesday/wednesday to push out the final release. I haven't been pushing this release hard enough. It's dragging on way too long... Sorry about that. Sander
Re: Tagged 2.0
Sander Striker wrote: I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2. I've put some tarballs containing that tag up at: There are some other fixes merged back since then, and it looks like another set of fixes that are close to being approved. Here is one issue I'd strongly suggest resolving for 2.0.48: Greg indicated in the last couple of days that www.apache.org had almost 12000 error messages (at that point) related to mutex errors with mod_rewrite. That affects flock users (e.g., FreeBSD) starting the server as root. I would suggest picking up this change to resolve that: -* Unix: Handle permissions settings for flock-based mutexes in - unixd_set_global|proc_mutex_perms(). Allow the functions to - be called for any type of mutex. PR 20312 -modules/mappers/mod_rewrite.c 1.153 -modules/ssl/mod_ssl.h 1.136 -modules/ssl/ssl_engine_config.c 1.81 -modules/ssl/ssl_engine_mutex.c 1.26 -os/unix/unixd.c 1.58 -os/unix/unixd.h 1.38 -+1: trawick, jerenkrantz, gregames - 0: jim (it seems to me that the locking mech itself - should have the required flags to determine whether - uid/gid and chown is required, rather than placing - that knowledge in unixd.c (kind of what is done for - the SSL stuff already with ChownMutexFile). Thus - unixd would simply check those out and do what is - required rather than having internal APR knowledge - it shouldn't). I think the critical issue with this one is that, while the lessor-used lock in mod_rewrite had this problem all along, another fix in 2.0.47 started doing the child-init on the other mod_rewrite lock and it too picked up the root/flock issue. Beyond this one, I'm afraid that I'm not very familiar with the real-world implications of not picking up the other available fixes. I'd like to think that within a couple of days we could get 7 or 8 more fixes merged back, at which point we'd be ready for another release anyway. But it wouldn't be prudent to count on that happening ;)
