Re: event MPM works with mod_ssl
On Mon, 27 Jun 2005, Greg Ames wrote: my biggest hurdle in getting the event MPM to work with mod_ssl was learning how to create a self signed server cert with openssl. http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#ownca is very good but refers to a sign.sh script that I couldn't find in httpd-2.x . I assume sign.sh was part of the 1.3 mod_ssl distro when it was separate from httpd. That is correct. It was removed intentionally (I think it was someone trying to discourage self-signed certificates?) but the docs were never updated to tell you how to do what it does, which is kind of a bummer. Personally I always just do a google search for sign.sh and use the old one anyway. --Cliff
Re: error
On Mon, 27 Jun 2005, Gustavo A. Baratto wrote: prefork.c:103: error: syntax error before '*' token prefork.c:103: warning: data definition has no type or storage class gmake[4]: *** [prefork.lo] Error 1 gmake[4]: Leaving directory `/home/admin2/src/httpd-2.0.54/server/mpm/prefork' Hmm, I'm not really sure how this never came up before. prefork.c:103 says: static ap_pod_t *pod; struct ap_pod_t is defined in mpm_common.h but only if AP_MPM_USES_POD is defined. server/mpm/prefork/mpm.h does define this symbol. But prefork.c does not include mpm.h at all, whereas it would have to do so prior to including mpm_common.h to pick up the definition of this data type. Anybody have any clue how this compiles at all anywhere?
Re: error
On Mon, 27 Jun 2005, Joe Orton wrote: mpm_common.h does itself include mpm.h fortunately, otherwise the ceiling would indeed have fallen in ;) Naturally, the one place I didn't look. :) Yeah that explains the lack of cave-ins. ;) Thanks Joe.
Re: Running unit test on mod_rewrite
On Fri, 10 Jun 2005 [EMAIL PROTECTED] wrote: Does anyone know of a way to run unit tests against mod_rewrite? Our unit tests are all in the httpd-test module, which you can check out from our repository. The tests are a bit more heavyweight than what you asked for, but they can still get the job done. You could possibly modify the httpd-test test harness to work the way you're wanting for that module. --Cliff
Re: RFC: Who owns a passed brigade?
On Mon, 25 Apr 2005, Joe Orton wrote: 1. update the util_filter.h documentation 2. add some APR_BUCKET_DEBUG code to abort() when brigades are used after being destroyed 3. adjust all filters to work with this model 4. switch to allocate brigades out of the bucket allocator Didn't we try #4 before and something bad happened? I don't remember what that would have been, I just feel certain #4 has been previously discussed at least. 5. profit (aka. closing all the memory leak bugs caused by this stuff in bugzilla) Otherwise, +1.
Re: File attachments...
On Mon, 25 Apr 2005, Nathanael Noblet wrote: Just curious, is there any reason someone on this list would intentionally attach a file with a .scr ending? Periodically I get the ezmlm program emailing me and complaining that sometimes my address bounces messages back. I've looked and it is because they contain files with the .scr ending. .scr, as was mentioned, is the windows screensaver extension. It's just an .exe with a different extension. Anyway if one of these tries to get through to the list, it's because some worm managed to forge a From: address of someone actually subscribed to the list when sending to the list. We do have antivirus software running on our mailserver at apache.org, but apparently it doesn't catch 100%. --Cliff
Re: Pool buckets, transient buckets and bucket_setaside
On Mon, 25 Apr 2005, Rici Lake wrote: Why do pool buckets do an automatic setaside? Should they? They set themselves aside when the pool in which their data was allocated is in the process of being destroyed. This is necessary because no other bucket type has a similarly unpredictable lifetime. Even transient buckets have a lifetime that is well-known: they last until the call chain returns. Pool buckets might not even live that long. Don't think just in terms of httpd's usage of buckets here -- this is an APR construct. If there were any way to have transient buckets automatically set themselves aside, then I would argue that that should be done, too. Of course there isn't, since there is no such thing as a callback that says the call chain has returned now. But at least as it stands now, we have a minimum guaranteed time that all of the buckets' data will live -- as long as the call chain lives. If brigades are (almost) always explicitly cleaned or destroyed, and buckets are always explicitly setaside, then what is the point of the overhead of registering auto-setaside functions for every pool bucket? If registering a pool cleanup that doesn't get called (on a bucket type that is rarely used in httpd, no less) has a measurable performance impact, I'd be extremely surprised. --Cliff
Re: Pool buckets, transient buckets and bucket_setaside
On Mon, 25 Apr 2005, Rici Lake wrote: Surely this is equally true of any pool-related resource. For example, a file which has been opened and has a pool cleanup registered would have exactly the same lifetime as a pool-allocated string. Hmm... for some reason I thought file buckets morphed themselves upon pool cleanup, too. That they don't could be viewed as a bug in file buckets. As an alternative, we could just add pool cleanups to the other types and make them all exist only in APR_BUCKET_DEBUG mode and assert(0) if the cleanup ever actually gets called. Let's move this discussion to [EMAIL PROTECTED] --Cliff
Re: RFC: Who owns a passed brigade?
On Thu, 21 Apr 2005, Paul Querna wrote: I agree that not having a clear rule has led to some possible leaks in many filters. If some people think there has always been a 'rule', I contend that it has never been documented. That may be. I *believe* the rule was supposed to be that once you handed it down, you could assume that it would come back empty. This was discussed at length on either httpd-dev or apr-dev back in the day. I'll have to dig through the archives to find it, though.
Re: RFC: Who owns a passed brigade?
On Thu, 21 Apr 2005, Paul Querna wrote: I agree that not having a clear rule has led to some possible leaks in many filters. If some people think there has always been a 'rule', I contend that it has never been documented. FWIW, the documentation says: /** * Pass the current bucket brigade down to the next filter on the filter * stack. The filter returns an apr_status_t value. If the bottom-most * filter doesn't write to the network, then ::AP_NOBODY_WROTE is returned. * The caller relinquishes ownership of the brigade. * @param filter The next filter in the chain * @param bucket The current bucket brigade */ AP_DECLARE(apr_status_t) ap_pass_brigade(ap_filter_t *filter, apr_bucket_brigade *bucket); The caller relinquishes ownership of the brigade. This obviously differs from what some of our own filters are doing -- and from my memory of past history. It makes sense that it should be this way, though I think at some point in the past we just guaranteed that the core_output_filter always emptied the brigades it was passed so it wouldn't have mattered until other filters that didn't behave that way started getting inserted in front of c_o_f. I'll keep digging.
Re: RFC: Who owns a passed brigade?
On Thu, 21 Apr 2005, Cliff Woolley wrote: The caller relinquishes ownership of the brigade. So that documentation came about because of this thread: http://marc.theaimsgroup.com/?l=apache-httpd-devm=106952637722748w=2 I'm not sure that the thread reflected reality, though. Perhaps it *should*, but it doesn't. Jeff? --Cliff
Re: Renaming mod_imap - mod_imagemap
Paul Querna wrote: From the 'Default Modules' thread for renaming mod_imap: +1 Dirk, nd, justin. If there are no objections I will rename mod_imap to mod_imagemap and all the documentation later tonight. +1
Re: Http/APR
On Mon, 21 Mar 2005, Nathanael Noblet wrote: Just wondering, if I install APR 1.X and then attempt to compile apache 2.0.X, can it use the newer APR? or does it use the built in 0.9.X version of apr? Apache 2.0.x is tied to APR 0.9.x for backward compatibility reasons. That doesn't stop you from having a concurrent installation of APR 1.x on the same machine, but Apache 2.0.x will not use it. --Cliff
Re: do we still want sendfile enabled with our default conf files?
On Fri, 18 Mar 2005, Ryan Bloom wrote: disabling sendfile solved it immediately. Seems to me that until our sendfile support is better, we should err on the side of always sending the data correctly instead of absolutely as fast as possible. I would much rather have APR default to not using the native sendfile, and only enable native sendfile when we have a lot of evidence that it does work correctly. Agreed on both points. +1 --Cliff
Re: Mod_MEM_cache doesn't use Pools to allocate cache objects???
On Tue, 8 Mar 2005, Bill Stoddard wrote: luca regini wrote: Taking a look at mod_mem_cache source code i have seen that it doesn't use pools to allocate cache objects but i does so by means of reference counting and simple calloc/free calls. I have also seen that this module requires a Threaded apr to work. I am wondering the reasons of this design choices. If you allocate the cache objects out of a pool, what happens to the memory when stale objects are garbage collected? Bad Things(tm). :) However, it should be possible to use a custom apr_allocator_t instead of directly calling calloc/free. Might be a little faster?
Re: Use of brigade_split...
On Fri, 18 Feb 2005, Paul Querna wrote: First, let me say that apr_brigade_split is evil. It is used in several filters to break up input, or temporarily store some buckets. The problem is that it allocates a new brigade, commonly out of the request pool. Feel free to write a variant that (also) takes as a parameter the brigade into which to split the second half. :)
Re: Permissions
On Sun, 16 Jan 2005, Jason Rigby wrote: Allow from all computers on the Internet, Deny from the 10.x.x.x subnet, Allow from a particular IP address within the 10.x.x.x subnet (ie 10.0.0.14) Sure, it's possible. Normally this is the kind of question that would be answered on the users's mailing list, but it would take me just as much time to tell you to go ask your question over there as it would to simply answer it. So here goes. :) Order deny,allow Deny from 10.0.0.0/255.0.0.0 Allow from 10.0.0.14 And you're done. :) As you can see from the Order documentation (http://httpd.apache.org/docs-2.0/mod/mod_access.html#order), order deny,allow has a default of allow. Any client which does not match a Deny directive or does match an Allow directive will be allowed access to the server. So you don't have to specify Allow from all explicitly, and that's the key to your puzzle. Hope this helps, --Cliff
Re: Dumb APR_BUCKET_BUFF_SIZE question
On Fri, 7 Jan 2005, Rasmus Lerdorf wrote: I still think it would be worthwhile to make it configurable. Linux or FreeBSD5 on IA64 with 16k pages, for example, might show some decent gains by setting that to 15000. Or do a getpagesize() call on startup to determine it dynamically. It might be. We've considered having it be configurable before. There are just a lot of implications in changing the value; for example, it affects the memory footprint of the server, it affects how much data gets read in to memory per read() call on a file bucket (which might alter the decision of whether read() or mmap() is preferable, for example), it affects how well the data fits into memory pages, and it affects how much data is buffered in one block for the scenarios you described. There are probably others I'm not thinking of right now, too. Lots of different axes that must be considered when trying to pick an optimal value. But still, if you want to make it configurable, go right ahead. :)
Re: Dumb APR_BUCKET_BUFF_SIZE question
On Fri, 7 Jan 2005, Rasmus Lerdorf wrote: Why is it hardcoded to be 8000? It would seem like you could easily be unlucky and just miss the cutoff and end up with a 6000 byte heap bucket followed by a 3000 byte transient bucket, for example, as a result of 3 3000 byte ap_rwrites. For that particular case it might be quite beneficial to increase APR_BUCKET_BUFF_SIZE to 9000 which would suggest that it might be something that should be configurable. In fact, it used to be 9000. Then we realized that that was causing cache/page alignment problems. So we changed it to be just a fuzz less than 8KB to allow it plus the bucket allocator structures to fit into one 8KB or two 4KB pages. --Cliff
Re: C-L or T-E: chunked for proxied request bodies
On Sat, 1 Jan 2005, Roy T.Fielding wrote: On Jan 1, 2005, at 1:38 PM, Justin Erenkrantz wrote: Apache 1.3 does not support chunked request bodies. (All 2.x GA releases do though.) So, that factors very much in the reason that I don't think we should send chunks by default: all requests to 1.3.x would receive some 4xx (413??) error if we tried to pass chunks. -- justin Umm, yes it does support chunked request bodies -- I wrote that code long before 2.0 even started. Only the CGI module doesn't support it because CGI depends on knowing the length in advance. Exactly... it definitely does support chunked request bodies. Remember CVE-2002-0392? --Cliff
Re: Client Authentication POST Problem (fwd)
This bug was filed a long time ago... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12355 Can somebody familiar with this part of mod_ssl do me a favor and take a look at it? Thank you! Merry Christmas, everyone. :) --Cliff -- Forwarded message -- Date: Sat, 25 Dec 2004 22:47:31 -0400 From: Adolfo Bello [EMAIL PROTECTED] Reply-To: modssl-users@modssl.org To: modssl-users@modssl.org Subject: Re: Client Authentication POST Problem On Sat, 2004-12-25 at 15:37 -0500, David T. Ashley wrote: Hi, I installed Bugzilla, and the directory it is in has the VerifyClient require and all the Apache directives set in the httpd.conf file. It works fine (the browsers makes me choose a client certificate) but when I submit a form into Bugzilla I get an error to the effect that POST is not allowed, and this appears in the Apache logs: [Fri Dec 24 19:59:24 2004] [error] SSL Re-negotiation in conjunction with POST method not supported!\nhint: try SSLOptions +OptRenegotiate I tried the fix recommended in the log message, but it doesn't work. I seemed to make it through one form OK, but then the next one got me the same error message, both displayed by the browser and in the Apache logs. Any other suggestions? Thanks, Dave. It just doesn't work in Apache 2.0.x. Use Apache 1.3.x. Adolfo Bello __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Re: [STATUS] (httpd-2.0) Wed Dec 15 23:45:15 EST 2004
I fixed it in SVN trunk. Ken's scripts are still checking this all out from the old CVS repository, which is now closed. Ken, please update your scripts. --Cliff On Thu, 16 Dec 2004, hutuworm wrote: 2.0.52 : released September 28, 2005 as GA. Sorry again. ;) On Wed, 15 Dec 2004 23:45:15 -0500, Rodent of Unusual Size [EMAIL PROTECTED] wrote: APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2004/11/10 18:05:46 $] Release: 2.0.53 : in development 2.0.52 : released September 28, 2005 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 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 or XXX in the source. * Review the PatchAvailable bugs in the bug database. Append a comment saying Reviewed and tested. * Open bugs in the bug database. RELEASE SHOWSTOPPERS: PATCHES TO BACKPORT FROM 2.1 [ please place file names and revisions from HEAD here, so it is easy to identify exactly what the proposed changes are! ] *) mod_ssl: Fix an possible NULL pointer dereference in some configs. http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=13182 PR: 31848 +1: jorton, wrowe, jim *) Allow for the use of --with-module=foo:bar where the ./modules/foo directory is a local addition to the ./modules directory. Assumes, of course, that the required files are in ./modules/foo, but makes it easier to statically build external modules by simply adding them to ./modules. modules/config5.m4: 1.4 +1: jim, jerenkrantz +0: wrowe (would rather see --with-module-lib=foo --enable-bar=shared syntax to support multiple libs, module modules. Might need to pass the --with-module-lib=foo to ./buildconf instead.) *) several changes to improve logging of connection-oriented errors, including ap_log_cerror() API (needs minor bump in addition to changes below) http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c?r1=1.289r2=1.291 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.150r2=1.151 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_log.h?r1=1.46r2=1.48 +1: trawick *) mod_auth_ldap: Handle the inconsistent way in which the MS LDAP library handles special characters. http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12919 PR 24437 +1: minfrin, wrowe, jim *) Fix ap_save_brigade's handling of ENOTIMPL setaside functions.
Re: svn commit: r111830 - /httpd/httpd/trunk/modules/proxy/mod_proxy.c /httpd/httpd/trunk/modules/proxy/mod_proxy.h /httpd/httpd/trunk/modules/proxy/proxy_ajp.c /httpd/httpd/trunk/modules/proxy/proxy_http
On Tue, 14 Dec 2004 [EMAIL PROTECTED] wrote: ap_rputs(apr_strfsize(worker-s-transfered, fbuf), r); trthWr/thtdNumber of bytes transfered/td/tr\n Furthermore, it's transferred. --Cliff
Re: mod_actions 1.32 patch never made it to 2.0
On Mon, 13 Dec 2004, Ryan Bloom wrote: A co-worker of mine pointed out that the following works in Apache 1.3, but not 2.0 if the location /foo, doesn't exist on the disk: AddHandler foobar /cgi-bin/printenv Location /foo SetHandler foobar /Location This patch ports this behavior forward into 2.0. r1.32 of mod_actions in the httpd-2.0 CVS module is a 2.1.x revision number. It adds a virtual option to the Action directive, which allows the use of handlers for virtual locations (according to the commit log), which I think does match up with what you're asking for here. But then why this patch instead of backporting r1.32 to the 2.0.x branch? Is there a revision number for similar behavior in apache 1.3? Oh, I see... that would be r1.33 of mod_actions in the apache-1.3 CVS module. That does indeed match up with your patch. So why is this same general behavior unconditional in httpd 1.3 but non-existant in 2.0 and requires a virtual flag on 2.1? Andre? Thoughts? The virtual thing was your doing... --Cliff
Re: svn commit: r111516 - /httpd/httpd/trunk/support/htcacheclean.c
On Fri, 10 Dec 2004, Jim Jagielski wrote: I just *hate* ^V-TAB to get real tabs though :) real tabs? feh. no such thing. ;)
Re: svn commit: r111516 - /httpd/httpd/trunk/support/htcacheclean.c
On Fri, 10 Dec 2004, Jim Jagielski wrote: Dang vi auto-tabbing :) set expandtab :)
Re: [STATUS] (httpd-2.0) Wed Dec 8 23:45:10 EST 2004
On Thu, 9 Dec 2004, hutuworm wrote: 2.0.52 : released September 28, 2005 as GA. should be 2.0.52 : released September 28, 2004 as GA. LOL. :) There's been a new breakthrough in home video marketing. Instant cassettes. They're out in stores before the movie is finished. I'll go fix that.
Re: mod_dumpio
On Tue, 7 Dec 2004, Jim Jagielski wrote: On Dec 6, 2004, at 5:28 PM, Cliff Woolley wrote: On Mon, 6 Dec 2004, William A. Rowe, Jr. wrote: Same location as mod_log_forensic? If you want to move them both into a modules/debug/ location, ++1. mod_bucketeer would be classified as a debugging module, also. It's currently under modules/test. Hmmm... maybe 'test' != 'debug' ?? ;) Oh, no, I agree with you. I was saying that mod_bucketeer should be MOVED, not that mod_dumpio should go in modules/test/. :-)
Re: MPM and AcceptMutex questions
On Fri, 3 Dec 2004, Andy Armstrong wrote: Kristina Clair wrote: I'm running apache2 on redhat 7.3 servers with very heavy http traffic. I'm wondering if it might be wise for me to try to use the worker MPM rather than the default prefork. Does anyone have any real-world experience with this? Our users are allowed to run any cgi scripts they want -- could this cause a potential problem with worker? As far as I know CGIs /always/ get their own process so they should be Well, it's slightly more complicated than that due to the the CGI gets spawned -- fork()ing a threaded process in order to exec() the CGI is not so nice. So on threaded MPMs, mod_cgid gets used instead of mod_cgi. It has a separate process that runs as a cgi daemon with which the server child processes communicate. It's that daemon that forks to exec the CGI script. --Cliff
Re: SVN problem
On Thu, 2 Dec 2004, Andy Armstrong wrote: This isn't supposed to happen is it? :) [EMAIL PROTECTED] apache]$ svn co \ http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-trunk svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: REPORT of '/repos/asf/!svn/vcc/default': 400 Bad Request (http://svn.apache.org) Having never used svn before (cvs luddite) I'm not sure how to diagnose it. I just tried the exact same command from minotaur and it worked fine for me... --Cliff
Re: SVN problem
On Thu, 2 Dec 2004, Garrett Rooney wrote: That is often the result of an uncooperative proxy in the middle, which doesn't understand (or pass through) the HTTP methods used in DAV. Try checking out via https:// (assuming you have a version of Subversion that has ssl support) and see if that fixes things. Aha! Thanks Garrett. --Cliff
Re: VirtualHost trafic
On Wed, 1 Dec 2004, [iso-8859-15] André Malo wrote: Furthermore I think you would need to donate the copyright to ASF (but I'm not sure about the latter). No. As long as it's licensed under the Apache License version 2, that gives us the right to redistribute it under the same terms, without any assignment of copyright being necessary. --Cliff
Re: signals under worker mpm?
On Mon, 29 Nov 2004, Stas Bekman wrote: ./include/ap_mpm.h unix/posix notes: - The MPM does not set a SIGALRM handler, user code may use SIGALRM. But the preferred method of handling timeouts is to use the timeouts provided by the BUFF abstraction. That's an ancient comment that dates back to Apache 1.3 and no longer applies to anything. BUFF no longer exists.
Re: signals under worker mpm?
On Mon, 29 Nov 2004, Stas Bekman wrote: nuke it? So this is incorrect? - The MPM does not set a SIGALRM handler, user code may use SIGALRM. It can use it if it knows what it's doing. A mod_perl module that's expected to work on any MPM (which is I'm assuming what you're talking about) is not going to fall into the category of knows what it's doing if it tries to use signals. :-)
Re: SVN broken?
On Fri, 26 Nov 2004, Mladen Turk wrote: Trying to: http://svn.apache.org/ or... https://svn.apache.org/ could not connect to server (http://svn.apache.org) Just me or thanksgiving :) I'm working on it. PS, Mladen: in the future, send things like this to infrastructure@ instead of [EMAIL PROTECTED], and they'll get looked at faster. --Cliff
RE: SVN server down? (fwd)
-- Forwarded message -- Date: Fri, 26 Nov 2004 13:06:19 -0500 From: Noel J. Bergman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Sylvain Wallez [EMAIL PROTECTED], [EMAIL PROTECTED], Shinobu Kawai [EMAIL PROTECTED], Jakarta General List [EMAIL PROTECTED] Subject: RE: SVN server down? Shinobu Kawai and others asked: Is the SVN server down? Yes. Currently doing some maintenance on the database. About another hour, I would estimate from the processing rate, so between 14:00 and 14:30 EST or so. Sorry for the inconvenience. Wasn't what I expected to be doing this morning, either. :-) --- Noel
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Thu, 25 Nov 2004, Joe Orton wrote: Or if it does, -1 veto on either bumping the APR major version or creating a branch or making toast with jam before Allan submits a patch for review on [EMAIL PROTECTED] Okay, well, that means that for progress to be made, some form of patch needs to get mailed in. Allan, go on and mail something in then. Joe's veto disappears at that point and THEN we can make a sandbox branch in the repository. Let's just not let this cause all action to be stopped. :) --Cliff
RE: svn down? (fwd)
It's back. Have fun. :) -- Forwarded message -- Date: Fri, 26 Nov 2004 15:18:08 -0500 From: Noel J. Bergman [EMAIL PROTECTED] To: Daniel John Debrunner [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: svn down? SVN was down for database maintanence. Is back up now. --- Noel
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Allan Edwards wrote: First order of business now that we are on SVN is to focus on the APR changes that are needed. It's not clear to me though, now that we have an APR 1.0 branch, is the trunk open for API-breaking changes or do we need a separate branch for that work? Just make yourself a branch in SVN of APR and do whatever you like. Branches are cheap and non-permanent in SVN. Once we merge it into the trunk, the trunk will likely have to become APR 2.0-dev. --Cliff
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote: Allan - your last patches were to try to -wedge- the current API into httpd. Can you share the patch just to fix APR? Then we can start to comprehend scope. NO CASTS - just the correct declarations in the first place. Since this is obviously going to be big, don't you think it would be better to just get going on a sandbox branch of APR so that we can work iteratively instead of passing big patches back and forth?
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Garrett Rooney wrote: I guess I'm just arguing for a single branch that's the target of the current development, as opposed to one 64 bit dev branch and one trunk which holds other changes, thus requiring us to either invest constant effort in merging changes from the trunk into the 64 bit branch or letting it get kind of stale and then having a mega-huge merge into the trunk at the end. The only question is whether we want to keep trunk as 1.1-dev or 2.0-dev. But I guess with SVN it's easy to branch 1.1 and 1.0 off of what's now the 1.0 branch (rename the 1.0 branch to 1.1 and branch a new 1.0 branch off of that, or whatever). So sure, screw it. APR trunk is now 2.0-dev. Have fun.
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Justin Erenkrantz wrote: Oh, please don't. We have *no* idea what the changes are or whether we'll even ultimately accept them. Please branch Allen's changes off in a sandbox (cp trunk branches/64-bit-changes) - let him get a workable version that we can then review, and then merge it in once we're done. But, these changes are too drastic and unknown to do the development in trunk. -- I'm sick of all talk and no action. We tried this last year when we were almost ready to branch APR 1.0 and all action on that front ceased entirely for a YEAR. This time it's one or the other. I'll wait 24 hours at most to hear opinions. Whichever route gets the most support wins. So far we have: trunk remains 1.1, 64-bit is sandboxed: jwoolley, jerenkrantz trunk becomes 2.0: rooneg --Cliff
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Justin Erenkrantz wrote: To be clear, I'm perfectly happy with merging to trunk in Allen's changes *once* completed and reviewed and moving trunk to 2.x if need be - but I Nevertheless, the question at hand is what action to take RIGHT NOW. Let's just wait for... with no action attached is not acceptable to me in this case, because it's bitten us in the ass before. So I'm waiting for votes. :) --Cliff
Re: [PATCH] another mod_deflate vs 304 response case
On Mon, 22 Nov 2004, Roy T. Fielding wrote: Quoting William A. Rowe, Jr. [EMAIL PROTECTED]: Okay, but why the next three lines? Why would Content-Encoding: gzip *ever* be set on a 304? Because Content-* header fields in a 304 response describe what the response entity would contain if it were a 200 response. Therefore, the header field must be the same as it would be for a 200. The body must be dropped by the HTTP filter. Aha. Yeah okay that makes total sense. Thanks Roy. :)
Re: Possible leak in core_output_filter()
On Tue, 23 Nov 2004, Ronald Park wrote: Now, for the bad news: we don't know if there's a specific single request that creates the problem. In fact, given that it mostly runs Blah, I was afraid of that. :-/ Now for the good news: we can probably run in production with debugging enabled (the overhead for extra debug code executing is probably negligible compared to overall download time for these huge files :D). So I'll see about getting that out there and report back with any findings. Okay, cool. You know, it would be really useful if there were a module that could track memory leaks related to buckets. I'm envisioning something like this: It has an input filter and an output filter. The input filter logs the request headers (let's just say no content body for the sake of simplicity), and the output filter logs the response. But for each one, what I'm more interested in than the content itself is that dump_brigade-style knowledge of what data was in what buckets, how big and of what type those bucket are, and which buckets were in the same brigade as opposed to separate brigades. So basically the output filter would just insert itself right above the core_output_filter and log all the buckets that fly by. It wouldn't be able to log the data contents of all bucket types without modifying the bucket (eg, file buckets), but like I say, I'm more interested in knowing the structure of the data than the data itself. The additional useful bit of information would be a log of what the RSS of the process was at the end of each request. I don't know if there's an easy way to get that information, but man would it be useful... --Cliff
Re: Possible leak in core_output_filter()
On Tue, 23 Nov 2004, Jim Jagielski wrote: http://www.apache.org/~jim/mod_dumpio.c Yeah. :-) But mod_dumpio calls apr_bucket_read() unconditionally on data buckets, which is exactly what I *don't* want it to do. Because that modifies the contents of the brigade. The module I'm looking for needs to be completely transparent. But it's a very good start. :-)
Re: [PATCH] another mod_deflate vs 304 response case
On Mon, 22 Nov 2004, Joe Orton wrote: There's another mod_deflate vs 304 response problem which is being triggered by ViewCVS on svn.apache.org: when a CGI script gives a Status: 304 response the brigade contains a CGI bucket then the EOS, so fails the if this brigade begins with EOS do nothing test added for the proxied-304 case. I wonder if the simplest fix is to just explicitly test for a 304/204 response instead. Were there any more EOS-only brigade cases this won't catch? Okay, but why the next three lines? Why would Content-Encoding: gzip *ever* be set on a 304?
Re: [PATCH] another mod_deflate vs 304 response case
On Mon, 22 Nov 2004, Joe Orton wrote: Okay, but why the next three lines? Why would Content-Encoding: gzip *ever* be set on a 304? I was wondering that too. The answer to the latter is that it *won't* be sent for a 304 because the http_header filter knows better than that. Well, okay. But should we even set it in that case? Is it correct to send it in the 204 case?
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote: Yes - I understand that this means 1.x will never be used by httpd. Version numbers are cheap. The APR project should become used to this, if they are active, and httpd moves at it's normal pace, it would be easy to go through APR 2.x, 3.x, and land somewhere in version 4.x by the time httpd 2.4 or 3.0 walks out the door. Do you understand how ridiculous that sounds?
Re: Whitespace strip filter for httpd v2.1
On Mon, 22 Nov 2004, Graham Leggett wrote: I have attached a small filter module that strips leading whitespace from text files. This would typically be used to remove the indenting whitespace found inside HTML files, resulting in a significant reduction in network traffic for some sites. I didn't bother to include trailing whitespace removal, as this involved buffering (leading whitespace removal requires no buffering). Well, we've had people submit modules in the past that stripped the extraneous whitespace from HTML files, and we rejected them. Check the archives for messages from a guy named fabio rohrich, who wrote a module called mod_blank to see why that might have been. I don't completely remember the details. --Cliff
Re: Possible leak in core_output_filter()
On Mon, 22 Nov 2004, Ronald Park wrote:
I'm investigating a difficult to diagnose problem and I came across the
following code in core_output_filter():
Yuck. I HATE the core_output_filter. I probably know that code as well
as anybody, and yet every time I look at it, it makes my brain hurt so bad
I want to scream. It's just a big pile of jumbled up intertwined
heuristics.
I can see I'm going to have to just break down and rewrite the damned
thing as a series of (gasp) SMALLER FUNCTIONS, rather than one big
monolithic beast.
But first, this bug.
It would be very helpful if you could do one or both of the following:
* compile with bucket debugging enabled (see slide 17 of
http://www.cs.virginia.edu/~jcw5q/talks/apache/apache2moddebugging.ppt)
* give me a list of the buckets in each brigade that gets passed in to
the core output filter in response to the request that reproduces the
problem. (set a breakpoint on the line:
4026 while (b !APR_BRIGADE_EMPTY(b)) {
and then run dump_brigade b in gdb each time the breakpoint gets hit)
--Cliff
Re: svn commit: r106072 - httpd/httpd/trunk/modules/http
On Sun, 21 Nov 2004 [EMAIL PROTECTED] wrote: Author: pquerna Date: Sat Nov 20 21:53:38 2004 New Revision: 106072 Modified: httpd/httpd/trunk/modules/http/http_request.c Log: Compile Fix for Netware Port with CodeWarrior. FYI, this would not be just a CodeWarrior thing... declaring variables in the middle of a function is not valid ANSI C. It's valid in C++, and unfortunately some broken C compilers allow C++ constructs to be used without complaint (cough MSVC). --Cliff
Re: People still using v1.3 - finding out why
On Fri, 19 Nov 2004, Peter Friend wrote: I don't work in the same group anymore, so I am not sure where we are with the 2. versions. I do know that we have large number of custom hacks in there, including one I did many moons ago for supporting hundreds of thousands of name based virtual hosts without having to enter them in the config file. That hack depended on the prefork model, and I haven't looked into porting it yet. And this is different from mod_vhost_alias in what way? --Cliff
2.2 roadmap meeting tomorrow
For any committers interested: we're going to do a lunch meeting tomorrow (Monday) over lunch. Place TBA. I propose Hamburger Mary's since it's close and I haven't been there yet this year. --Cliff
Re: Apr array functions
On Mon, 8 Nov 2004, Nathanael Noblet wrote:
so that someone can use the array elements without removing them? Is
there something I don't know that gives a reason why this is bad?
You don't have to remove elements to get at them... the array header
structure is visible to the application, so it can just do
arr-elts[index] and be done with it (insert bounds checking if
necessary).
APR_DECLARE(void *) apr_array_get_element(aprt_array_header_t *arr, int
index)
{
if(apr_is_empty_array(arr)) {
return NULL;
}
if(index arr-nelts) {
return NULL;
}
if(index == 0) {
return arr-elts;
}
return arr-elts+(arr-elt_size * (arr-nelts-1));
}
Anyway, if this function is supposed to do what I expect it's supposed to
do, it seems to have several important bugs. I assume you just typed this
up off the top of your head and never actually tried to compile it or use
it. :)
* apr_array_header_t, not aprt_array_header_t
* the index==0 thing is superfluous
* ..except that otherwise index is never used and so you can only ever
return NULL, the first element, or the last element. :)
* you perform arithmetic on a void pointer
Anyway like I said it was probably just off the top of your head and
it was obviously enough to get the point across, so no big deal.
Also, of course it's not your bug, but:
* apr_is_empty_array ... ooh, that's annoying. Why did we not rename
that to apr_array_is_empty prior to APR 1.0? :-(
--Cliff
Re: Apr array functions
Btw: didn't notice ahead of time that this discussion was on [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Oh well. On Mon, 8 Nov 2004, Cliff Woolley wrote: You don't have to remove elements to get at them... the array header structure is visible to the application, so it can just do arr-elts[index] and be done with it (insert bounds checking if necessary). To be more precise, since arr-elts is a void pointer, you have to insert a cast here. But it doesn't have to be as complex looking as asking the array structure how big each element is and explicitly multiplying. Presumably the application code knows what actualy type the data stored in the array is, and thus a cast and pointer arithmetic will do the job for you. ((foo_t *)arr-elts)[index] Or, even better: foo_t *f = arr-elts; f[index] ... --Cliff
Re: Apr array functions
On Mon, 8 Nov 2004, Nathanael Noblet wrote: Though your assumption about the function I typed in my email, I did type it off the top of my head thus the typos, lots of logic in there is actually from the apr_array_pop() function. If you didn't like the arithmetic on those structure members, perhaps someone should look there. I'm not saying this because I'm hurt or angry, just to inform you of the fact that it exists in the apr source... Oh sure. Well in that case, it makes sense, because the apr function doesn't know what the underlying data type is and so it *has to* do the size multiplication itself. I was just trying to give you the cleanest version you could use if you did it in your own code that *did* know the actual datatype. :) Anyway glad that will work for you. Apache does tons of that kind of direct indexing into APR arrays, or at least it used to. That's why we never thought to add such a function. I'm not saying it's necessarily a bad idea to add one from an API-completeness point of view. :) But if we're going to have that discussion, let's do it on [EMAIL PROTECTED] Thanks! --Cliff
Re: suggestion: strip comments from served html pages
On Sun, 7 Nov 2004, Nick Kew wrote: On Sun, 7 Nov 2004, Tobias Skytte wrote: Why not introduce and option to remove the comments from the served file? You have that option from mod_xmlns, mod_proxy_html or mod_publisher, to name but three. Along with caveats about why it's not necessarily a good idea. Yes, I'm aware of at least one more 3rd-party module that does the same thing. I can't remember the name of it, but it was discussed on this list a while back (maybe a year ago now). Ultimately I suspect that the biggest problem (assuming that the what's a comment and what isn't problem is solvable) is that this kind of parsing takes a disproportionately large amount of CPU time with respect to the amount of network bandwidth it saves. I mean really, how much bandwidth from *html* are we talking about? Compared to images? If you start parsing the html, you lose any ability to do zero-copy and the like, not to mention the fact that the CPU has to examine every single byte of the input and process and/or copy it. Yuck.
Re: Use threaded MPM by default was Re: cvs commit: httpd-2.0 STATUS
On Sat, 6 Nov 2004, Geoffrey Young wrote: MPM on a platform that does not support it, the build process silently switches to prefork (or whatever the default is for the platform, I guess) now, I haven't seen this myself, so I don't want to propagate FUD, but if it's true I might suggest that halting the build process is preferable to switching behind the scenes (or even switching with a little warning) - from That does seem to match my memory of the situation, fwiw. I would have no problem with halting the build if they specified --with-threads and none were available, though I would have a problem with halting the build if using a threaded MPM were simply used by default and none were available. --Cliff
Re: [PATCH] add ap_brigade_insert_file()
On Sat, 6 Nov 2004, Justin Erenkrantz wrote: Point to note that if it goes into APR, it'd have to be in APR-util 1.1. I'd be fine with making httpd depend on 1.1+, but... So, perhaps httpd is 'right' after all. -- justin Well, there's no reason it can't go into apu 1.1 and be backported to httpd in the meanwhile, if you take my meaning.
Re: [PATCH] add ap_brigade_insert_file()
On Thu, 4 Nov 2004, Joe Orton wrote: This factors out the logic for correctly inserting a file into a brigade, doing the special little dance for large files if necessary; the code was already duplicated twice and it's needed in other places too. (pervasive largefile support being my top 2.1 goal :) Amen, brother. Thank you! :) Any comments, naming preferences, put it in apr-util you twit flames? I'd have absolutely no objection to that. Sounds like a fabulous idea actually. --Cliff
Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t
On Thu, 28 Oct 2004, Geoffrey Young wrote: I get the following failures on 1.3.32 but not on 1.3.33. t/modules/rewrite.t 222 9.09% 18 20 t/security/CAN-2004-0940.t11 100.00% 1 t/security/CAN-2004-0958.t92 22.22% 1 3 I think these are all recent additions from you. should each of these failures be skipped unless something like ( have_apache(1) have_min_apache_version(1.3.33) ) || ( have_apache(2) have_min_apache_version(2.0.XX) ) I don't think so -- it's detecting an actual legitimate failure. It's not that the test requires a new version to work right, it's that that particular version was broken. No sense obfuscating that fact. --Cliff
Re: Test suite for SSI
On Sat, 23 Oct 2004, Nick Kew wrote: Before proceeding further, I'd like to validate it against any available test suite for SSI/mod_include. Does such a thing exist? Yes, there's a fairly extensive (though certainly not exhaustive) set of mod_include tests in httpd-test/perl-framework/t/modules/include.t . --Cliff
Re: OpenSSL with Security Processor
On Thu, 21 Oct 2004, Gurpreet Grewal wrote: Any clues where in the OpenSSL code I should be looking for ensuring that SSL card is actually being used for processing? Looking into openssl-0.9.7d\crypto\engine\hw_ubsec.c didn't help much? You should direct this question to the openssl mailing lists. :-) Have a look at http://www.openssl.org/ for details on what the correct list to send to would be. Thanks, Cliff
Re: [PATCH] Site, ApacheCon 2004
On Sat, 16 Oct 2004, Sander Striker wrote: I did some mods to the site, highlighting all sessions about httpd, but frankly, it looks totally messy. If someone with a bright idea on how to make this look better wants to take a stab at it, that would be much appreciated. I table-ized it and I think it's reasonable now. I'll just go ahead and commit it to httpd-site and if anybody wants to tweak it they can do it live. --Cliff
[announce] APR 1.0 Tutorial at ApacheCon
Sorry for the spam, but I just wanted to get the word out about the APR 1.0 Tutorial that Sander and I are doing at ApacheCon. We're hoping that some of you all who lurk on these lists and are interested in learning more about APR and the interface and features it provides might be able to convince your bosses to pay for you to come to the con and attend our tutorial. It's a three hour in-depth look at APR and how to use it. The full abstract is below. If you're interested, sign up asap -- if the number of people registered doesn't improve soon we might have to cancel the class altogether. Hope to see you there, Cliff T03: Apache Portable Runtime 1.0 Tutorial Day: Sat Time: 09h00 Session chair: None assigned Duration: 180 minutes Style: Tutorial Level: Experienced Audience: Developer Categories: Speaker: Cliff Woolley Speaker: Sander Striker As any systems programmer will know, one of the biggest headaches in writing a cross-platform application is dealing with the inconsistencies between various operating systems when trying to accomplish a given task. The Apache Portable Runtime is a portability library that seeks to bridge the gaps among these different platforms by providing a consistent interface for them all while attempting to provide maximum performance on each. It forms the underpinnings of both the Apache HTTP Server 2.0 and the Subversion revision control system, among other applications, freeing them from having to handle each new operating system as a special case. Though APR has been in development for several years, version 1.0 has finally hit the streets in its final form. This tutorial will give an overview of the features and APIs provided by APR 1.0 plus examples of how to use these features to make your own applications portable with ease. We will also demonstrate how APR's subsystems can be used together to build more complex applications by using them to construct a simple, portable web client that can fetch pages from a webserver and write them to disk.
Re: mod_status idea
On Fri, 8 Oct 2004, Eli Marmor wrote: Please check, before adding dependencies on internal data of mod_status, if APR_OPTIONAL_HOOK can help here; mod_status.c defines a status_hook, and maybe it can be used to help. Actually, we would want in this case would be an optional function, not an optional hook. It's a small distinction, but important: an optional function is a function that can be called when needed, if present, by a single caller at a time. An optional hook is a type of hook, rather than a single function call: it is a place in the API where a callback can occur, and multiple modules can register to participate in that hook in a certain loosely-specified order. The optional part is that the module that /defines/ the hook (and calls it) might not actually be present itself, so modules that wish to participate in that hook should not be broken by that other module's absense. In other words: callers callees optional hook ONE MANY optional function MANY ONE I do like the idea in general by the way. Hope this helps, Cliff
Re: Capturing a Subrequest
On Fri, 8 Oct 2004, Paul Querna wrote: So, I think something about my manually adding my output filter to the subrequest is wrong: Ya, that doesn't look right. There a function that's called (or at least used to be called ;) ap_add_output_filter(). That's probably what you want. --Cliff
Re: Bye bye welcome page
On Wed, 6 Oct 2004, [ISO-8859-15] André Malo wrote: - there are 1000 people with 1000 other opinions. For that reason, I'm ++1 for taking this minimalistic variant. Otherwise we get never a consensus about this darn dummy page. That's an exceedingly good point. Make it so. :) +1. --Cliff
RE: Bye bye welcome page
On Wed, 6 Oct 2004, Sander Striker wrote: We can always go with simply displaying a meaningless word like 'Waboozle'. I can see the bugtraq advisory now: Waboozle virus on the loose. ;)
Re: Bye bye welcome page
On Tue, 5 Oct 2004, Graham Leggett wrote: Point... How about The website you have accessed has not yet been Or: The website you have accessed is running but has not yet been... that speaks to both. configured. Please try to access this website again later.? It's directed at end users, and does not imply anywhere that the server might be running on their local machine. Regards, Graham --
Re: segfault in worker mpm
On Sun, 3 Oct 2004, Stas Bekman wrote: modperl-2.0 'make test' running under worker mpm (linux) always fails in t/filter/both_str_req_add.t and dumps core: #0 0xe410 in ?? () (gdb) bt #0 0xe410 in ?? () #1 0xbfffeff8 in ?? () #2 0x0001 in ?? () #3 0xbfffeff7 in ?? () #4 0x4030536b in __read_nocancel () from /lib/tls/libpthread.so.0 #5 0x080e03c3 in ap_mpm_pod_check (pod=0x817b250) at pod.c:53 My only guess of things to check out right off hand: Is the pipe that's being read from still a valid fd? (Maybe it somehow got closed elsewhere by some other thread accidentally? Such things have happened before...) --Cliff
Re: ap_save_brigade vs ENOTIMPL setaside
On Fri, 1 Oct 2004, Joe Orton wrote: current mod_perl installations. The mod_perl guys know that the lack of -setaside() is a bug and are working on that for future releases. So a better proposal is this: if setaside() == ENOTIMPL, read() == OK, and then setaside() still == ENOTIMPL, then still carry on and setaside the rest of buckets in the brigade, but do return the error. Is this OK? +1, sounds like a good compromise. --Cliff
Re: cvs commit: httpd-2.0/modules/proxy mod_proxy.c proxy_balancer.c proxy_util.c mod_proxy.h
On Tue, 28 Sep 2004, Graham Leggett wrote: I'm sorry guys, I've committed those two with CR-LF line endings, and figure out that after the commit. Will be more careful in the future. Not my day obviously :(. No big deal, thanks for fixing it. In theory, the only way CRLF would be a problem is if they were checked in as binary files instead of ASCII...? Actually what happens more often is that the files get edited under windows and then checked in using a unix-based CVS client that does not do the CRLF-LF conversion on ascii files. --Cliff
Re: EOS bucket data?
On Fri, 24 Sep 2004, Brian Akins wrote: Can an EOS bucket ever have data a filter needs to read? Nope. :) That's what the APR_BUCKET_IS_METADATA flag (or whatever we ended up calling it) is supposed to tell you. --Cliff
Re: EOS bucket data?
On Fri, 24 Sep 2004, Brian Akins wrote: So read from any thing !APR_BUCKET_IS_METADATA Yep. It doesn't hurt anything to read from a metadata bucket, you just don't *have* to do it. --Cliff
Re: [OT] Developer lists and Reply-To header
On Thu, 23 Sep 2004, Mladen Turk wrote: I found myself couple of times replying to the original sender by default, while my intention was to reply to the list. The solution is either to 'reply to all' (why would anyone wish to receive two messages about the same subject?) or doing that by hand. We all just reply-to-all typically. We've gone back and forth about this many times in the past and I suppose just ended up deciding that most of us preferred it this way rather than the other way. Shrug. --Cliff
Re: ap_save_brigade vs ENOTIMPL setaside
On Thu, 23 Sep 2004, Joe Orton wrote: /* ### this ENOTIMPL will go away once we implement setaside ### for all bucket types. */ then that would surely work correctly. Or will I find a massive flameware about this 3 years ago if I search the list archives, I dread to look... hahha Yeah, it's there. In fact there were several threads about this over the course of probably several years. I'll go find them for you. --Cliff
Re: ap_save_brigade vs ENOTIMPL setaside
On Thu, 23 Sep 2004, Joe Orton wrote: I committed a hacky workaround for this to HEAD, but I think the real bug is that nobody fixed this TODO in ap_save_brigade: /* ### this ENOTIMPL will go away once we implement setaside ### for all bucket types. */ Take a look at this: http://marc.theaimsgroup.com/?l=apache-httpd-devm=108497679222669w=2 In short: yes, it's a bug. Your proposed pseudocode fix is correct AFAIK. --Cliff
Re: [PATCH] APR_BUCKET_INSERT_BEFORE in mod_logio.c
On Sun, 19 Sep 2004, Joe Schaefer wrote:
Index: modules/loggers/mod_logio.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/loggers/mod_logio.c,v
retrieving revision 1.8
diff -u -r1.8 mod_logio.c
--- modules/loggers/mod_logio.c 3 Apr 2004 20:50:00 - 1.8
+++ modules/loggers/mod_logio.c 19 Sep 2004 23:31:33 -
@@ -127,8 +127,12 @@
/* End of data, make sure we flush */
if (APR_BUCKET_IS_EOS(b)) {
-APR_BUCKET_INSERT_BEFORE(b,
- apr_bucket_flush_create(f-c-bucket_alloc));
+apr_bucket *flush = apr_bucket_flush_create(f-c-bucket_alloc);
+
+if (b != APR_BRIGADE_FIRST(bb))
+APR_BUCKET_INSERT_BEFORE(b, flush);
+else
+APR_BRIGADE_INSERT_HEAD(bb, flush);
}
return ap_pass_brigade(f-next, bb);
Zuh? This is completely unnecessary. The only time inserting can corrupt
a brigade is if the bucket being inserted is still on some other brigade
(ie, you're inserting it onto brigade b before removing it from brigade
a). In this case, the bucket being inserted is freshly created, so
there's no problem at all. There must be some other problem.
--Cliff
Re: [PATCH] APR_BUCKET_INSERT_BEFORE in mod_logio.c
On Mon, 20 Sep 2004, Cliff Woolley wrote: (ie, you're inserting it onto brigade b before removing it from brigade a). PS: I should mention that in this case, it's brigade a that will be corrupt, not brigade b, since the inserted bucket's prev and next pointers will simply be overwritten. Brigade b will thus remain self-consistent. Brigade a, however, will still have pointers to the now-moved bucket, so as you traverse brigade a, you'll end up jumping over onto brigade b at some point and never get back to brigade a. Badness ensues at that point, the usual symptom of which is that you're traversing brigade a and you end up somehow seeing brigade b's sentinel as if it were somehow yet another bucket on brigade a. You try to deref the bucket pointers for brigade b's sentinel (which don't exist) and you go boom. Hope this helps. --Cliff
Re: [PATCH] APR_BUCKET_INSERT_BEFORE in mod_logio.c
On Mon, 20 Sep 2004, Joe Schaefer wrote: Thanks, Cliff. I guess I was getting confused by the warnings in the apr_ring.h docs. If you can be more specific about what part confused you, I'd be happy to rewrite said docs. If they're confusing as they stand, it's probably my fault anyway. :) % gdb /usr/local/apache2/bin/httpd -core /home/c/apache/modperl-2.0/t/core.9055 [...] #0 0x002a9590b2ca in apr_bucket_free (mem=0x35b39e8) at buckets/apr_buckets_alloc.c:174 174 apr_allocator_free(list-allocator, node-memnode); (gdb) bt #0 0x002a9590b2ca in apr_bucket_free (mem=0x35b39e8) at buckets/apr_buckets_alloc.c:174 Have you tried compiling with bucket debugging enabled? (See page 17 of my slides from last year's apachecon at http://www.cs.virginia.edu/~jcw5q/talks/apache/apache2moddebugging.pdf for help on how to do that.) 174 apr_allocator_free(list-allocator, node-memnode); (gdb) p list $5 = (apr_bucket_alloc_t *) 0x0 Um, that's bad. :) Try the bucket debugging code. That will insert bucket/brigade self-consistency checks and checks for double-free and the like in a bunch of strategic locations that should help find the actual problem rather than what you're seeing here, which I suspect is kind of a red herring because you're probably looking at the after-effects of some data structure corruption that happened at some point earlier. --Cliff
Re: [PATCH] APR_BUCKET_INSERT_BEFORE in mod_logio.c
On Mon, 20 Sep 2004, Joe Schaefer wrote: Pretty much all the @warning sections that begin with This doesn't work..., i.e. /** * Insert the element nep into the ring before element lep * (..lep.. becomes ..nep..lep..) * @warning This doesn't work for inserting before the first element or on * empty rings... see APR_RING_INSERT_HEAD for one that does * @param lep Element in the ring to insert before * @param nep Element to insert * @param link The name of the APR_RING_ENTRY in the element struct */ #define APR_RING_INSERT_BEFORE(lep, nep, link)\ APR_RING_SPLICE_BEFORE((lep), (nep), (nep), link) Hmm, okay. That warning only applies to certain kinds of rings -- namely rings where the offset between the value of the pointer to the head structure and the value used as the sentinel is nonzero. Brigades don't fall into that category. I've never even really seen the point for having such a beast at all, actually. So yeah, the warning could be more specific, but it does apply in general to rings even though not to the specific type of rings used by the bucket brigades. --Cliff
Re: Bug 18388: cookies
On Tue, 31 Aug 2004, Jim Jagielski wrote: Personally, I think that if Roy said that it would cause non-compliance then, unless he changed his mind, that's good enough for me to veto any change that would add Set-Cookie. I strongly agree. Roy? --Cliff
Re: [PATCH] mod_cache fixes: #9
On Mon, 2 Aug 2004, Roy T.Fielding wrote: Hmm, IIRC, loading a cache means writing to it, not reading from it. Doh. That does ring a bell in the back of my (usually lousy) memory. :) Why not just change them to cache_write and cache_read? Or store and recall? store and recall seem reasonable to me. Kudos on the other changes -- those are some significant improvements. Yeah, it's really good to see the interest in this picking back up. This seems like a really good way to get us motivated to do a 2.2 release Sometime Soon. :) --Cliff
Re: [PATCH] mod_cache fixes: #9
On Mon, 2 Aug 2004, Bill Stoddard wrote: How 'bout 2.2 GA for ApacheCon? Seems reasonable to me. ;-) -- justin +1, sounds like a good target to shoot for. +1
Re: Advice on bumping the mmn
On Fri, 18 Jun 2004, Jean-Jacques Clar wrote: A new API was added in APR (apr_procattr_addrspace_set()) with changes bubbling up in httpd-2.0-head.The API is relevant on NetWare and a no-op on all other platforms. This alone would not require a MMN bump. new field in apr_procattr_t and cgi_exec_info_t structures This, however, would require one, if a module would ever be responsible for allocating the apr_procattr_t or cgi_exec_info_t themselves, since if they're and old build, they'd allocate too little space. With the apr_procattr_t, I'd imagine the answer is no -- surely APR itself allocates that. What about cgi_exec_info_t? --Cliff
Re: dynamic hook ordering
On Fri, 18 Jun 2004, Geoffrey Young wrote: any feedback on this? the original patch is here: http://marc.theaimsgroup.com/?l=apache-httpd-devm=108693011011443w=2 Sorry, had forgotten to go back and review. I'm forwarding it to my at-work email addr (which doesn't have 59,000 msgs in the inbox ;) so it'll be on my todo list. --Cliff
Re: huge memory leak in 2.0.x
On Tue, 15 Jun 2004, Joe Orton wrote:
2) allocate brigade structures using the bucket allocator
If you're going to do this, then surely you need to call
apr_pool_cleanup_register() somewhere?
===
RCS file: /home/cvs/apr-util/buckets/apr_brigade.c,v
retrieving revision 1.60
diff -u -r1.60 apr_brigade.c
--- buckets/apr_brigade.c 13 Feb 2004 09:55:25 - 1.60
+++ buckets/apr_brigade.c 15 Jun 2004 15:34:47 -
@@ -30,7 +30,9 @@
static apr_status_t brigade_cleanup(void *data)
{
-return apr_brigade_cleanup(data);
+apr_status_t rv = apr_brigade_cleanup(data);
+apr_bucket_free(data);
+return rv;
}
APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data)
@@ -42,14 +44,12 @@
e = APR_BRIGADE_FIRST(b);
apr_bucket_delete(e);
}
-/* We don't need to free(bb) because it's allocated from a pool. */
return APR_SUCCESS;
}
APU_DECLARE(apr_status_t) apr_brigade_destroy(apr_bucket_brigade *b)
{
-apr_pool_cleanup_kill(b-p, b, brigade_cleanup);
-return apr_brigade_cleanup(b);
+return apr_pool_cleanup_run(b-p, b, brigade_cleanup);
}
APU_DECLARE(apr_bucket_brigade *) apr_brigade_create(apr_pool_t *p,
@@ -57,7 +57,7 @@
{
apr_bucket_brigade *b;
-b = apr_palloc(p, sizeof(*b));
+b = apr_bucket_alloc(sizeof *b, list);
b-p = p;
b-bucket_alloc = list;
Re: huge memory leak in 2.0.x
On Tue, 15 Jun 2004, Joe Orton wrote: apr_brigade_create() does that already. Oh, duh, of course it does. As many times as I've looked at that line, you'd think I'd have it memorized by now. :)
Re: cvs commit: httpd-2.0/modules/echo mod_echo.c
On Tue, 15 Jun 2004 [EMAIL PROTECTED] wrote: * modules/echo/mod_echo.c (process_echo_connection): Fix brigade handling: don't re-use a passed brigade. Hang on.. why is the passed brigade getting destroyed? You're supposed to be able to reuse your brigades after the call stack has returned to you--that's why if a later filter wants to stash all the buckets in the brigade you've passed them, they have to create their own brigade to put them in. Brigade reuse is why there's a distinction between apr_brigade_cleanup() and apr_brigade_destroy()... sounds like there's a destroy somewhere that ought to be a cleanup. --Cliff
Re: cvs commit: httpd-2.0/modules/echo mod_echo.c
On Tue, 15 Jun 2004, Joe Orton wrote: Hmmm, doing anything with a brigade after you pass it on to the next filter surely breaks the golden caller relinquishes ownership of the brigade rule for using ap_pass_brigade()? I'm saying I thought the rule was expressly opposite that. :) core_output_filter destroys the brigade - if it didn't, the patches I posted wouldn't be sufficient to fix the memory consumption problem. The alternative is to go through and find all the places where brigades are created and add _destroy calls everywhere as necessary. That would perhaps be safer by not breaking existing filters, but it seems ugly and would also surely just leave more memory leaks waiting to happen... Lemme ponder that and check around to see if we explicitly said anywhere that you were supposed to be able to keep old brigades after passing them. My main concern is that if we keep your changes as-is, it might mean we're constrained not to backport those changes to the APACHE_2_0_BRANCH because of breaking backward compatibility.
Re: Accept Filter Backport Request
On Thu, 10 Jun 2004, Paul Querna wrote: Pretty simple change, is there any chance someone can start a vote on getting it backported to the 2.0 Branch? done. i'll review it myself sometime tonight.
Re: [PATCH] mod_deflate + mod_proxy bug
On Wed, 9 Jun 2004, Allan Edwards wrote:
+}
+else {
+/* this was a zero length response, remove gzip header bucket then
pass down the EOS */
+APR_BUCKET_REMOVE(APR_BRIGADE_FIRST(ctx-bb));
+APR_BUCKET_REMOVE(e);
+APR_BRIGADE_INSERT_TAIL(ctx-bb, e);
+return ap_pass_brigade(f-next, ctx-bb);
+}
I haven't looked at the entire context of this, but if you remove a bucket
(brigade_first(ctx-bb) from a brigade without deleting it and without
having any extra pointers to it, you'll leak memory.
Also, what happens if e *is* the first bucket in the brigade? Can that
occur? I think that by coincidence given the implementation of
APR_BUCKET_REMOVE, nothing bad would happen by double-removing a given
bucket twice in a row, but in general that seems like a bad idea and
should be avoided.
--Cliff
Re: [PATCH] mod_deflate + mod_proxy bug
On Wed, 9 Jun 2004, Allan Edwards wrote: Also just realized I need to add a call to deflateEnd(). Oh right, that too. :-) e is on the brigade passed into deflate_out_filter and the gzip header bucket is in ctx-bb so that is not a problem. Ah, yeah, that would make sense. Cool.
Re: dynamic hook ordering
On Wed, 9 Jun 2004, Geoffrey Young wrote: I wanted to ping everyone about an idea I've been throwing around for a few months now. I'd like the ability to shuffle the declared hook ordering around, most likely during the post-config phase. There was some discussion about this or something at least vaguely like it a while back, but nobody ever got around to implementing it. See http://marc.theaimsgroup.com/?l=apache-httpd-devm=106637026719893w=2 But sure, feel free, have at it. :) --Cliff
Re: reading string in apache
On Fri, 4 Jun 2004 [EMAIL PROTECTED] wrote: Who write or modificate code mod_ssl or other module? Respond to me, please. A number of people have contributed to the mod_ssl that ships with Apache 2.0. How can read string, if standart C function not work in apache. What is method read? I'm not sure I understand your question. What do you mean standard C functions do not work in Apache? You mean like printf/scanf/etc? Well that's just because Apache's not reading from stdin and writing to stdout. What is method read? What exactly are you trying to read, and from where, and in what version of Apache? --Cliff
Re: is it possible to mark buckets to be copied only when to be set-aside?
On Wed, 19 May 2004, William A. Rowe, Jr. wrote:
It's a bug in mod_xslt, if that module trys to set aside a transient bucket.
Huh? No it isn't. Half of the reason setaside() even exists is to handle
transient buckets.
static apr_status_t transient_bucket_setaside(apr_bucket *b, apr_pool_t *pool)
{
b = apr_bucket_heap_make(b, (char *)b-data + b-start, b-length, NULL);
if (b == NULL) {
return APR_ENOMEM;
}
return APR_SUCCESS;
}
In other words, setting aside a transient bucket does exactly what you
want -- it copies the data into a new buffer allocated on the heap. So I
think mod_perl is doing the right thing by using a transient bucket here,
and I think mod_xslt is doing the right thing by calling setaside.
However, setaside is supposed to be used prior to returning from any
function in the current call stack, not just when you want to keep a
bucket past the end of the current request.
In other words, if any filter wants to keep a bucket and return to its
caller rather than passing that bucket to the next filter, it should call
setaside on that bucket. Failing to do so won't be a problem for most
bucket types, but it most assuredly WILL be a problem for transient
buckets, by the definition of transient: the storage behind a transient
bucket is only guaranteed to exist and have the desired data in it until
you return back into the function that created that bucket.
Note: ap_save_brigade() handles the setaside and brigade concatenation for
you. I suspect there are a number of places in the code that we are
incorrectly calling APR_BRIGADE_CONCAT() instead of ap_save_brigade().
That's bug city right there.
--Cliff
Re: is it possible to mark buckets to be copied only when to be set-aside?
On Wed, 19 May 2004, Cliff Woolley wrote:
Note: ap_save_brigade() handles the setaside and brigade concatenation for
you. I suspect there are a number of places in the code that we are
incorrectly calling APR_BRIGADE_CONCAT() instead of ap_save_brigade().
That's bug city right there.
Worse, there are probably places in the code where we don't even use
APR_BRIGADE_CONCAT() and simply append each bucket one at a time from the
source brigade to the saved brigade using APR_BRIGADE_INSERT_TAIL() (or
even APR_BUCKET_INSERT_AFTER(), though it's hard for me to imagine a case
where doing it that way would have made sense to the programmer).
Furthermore, I just found a bug in ap_save_brigade(). On line 534 of
util_filter.c:
rv = apr_bucket_setaside(e, p);
if (rv != APR_SUCCESS
/* ### this ENOTIMPL will go away once we implement setaside
### for all bucket types. */
rv != APR_ENOTIMPL) {
return rv;
}
Note that ### comment? Yeah it denotes what at this point is a bug. You
can't just ignore APR_ENOTIMPL for bucket types, because pipe and socket
buckets never had setaside implemented on them. I thought I remembered
that that was because Greg and Ryan and I had some huge debate about it
and it was decided for some reason that setting aside a pipe or socket
didn't make sense. But now I can't find where we talked about that in the
archives. Anyway, when Greg originally wrote the lines in question (see
http://marc.theaimsgroup.com/?l=apr-devm=99190977519715w=2), he
obviously did so assuming that setaside would be implemented on all bucket
types. It was not.
I recommend that the interested reader go back and take a look at the
following thread (this kind of starts somewhere in the middle but this one
message and its followups are particularly relevant):
http://marc.theaimsgroup.com/?l=apr-devm=99178798619777w=2
As it is, given the current State Of The Buckets: If rv == APR_ENOTIMPL
when you call apr_bucket_setaside(), then you're supposed to call
apr_bucket_read(), get the data out of the bucket, and stick it into a
heap bucket. ap_save_brigade() could possibly do a little optimizing here
in the special cases of socket and pipe buckets, and grab the actual APR
socket or pipe out of the bucket's internal data and compare the
socket/pipe's pool to pool p. If they already match, you don't have to do
the read and make-into-heap-bucket process; the reason being is that the
point of setaside is to tell the buckets code that you want it to
guarantee that the data storage behind bucket e will live at least as long
as pool p.
I thought I could just refer for some of this back to either of my sets of
ApacheCon slides, but I can see I discussed setaside() insufficiently well
at both ApacheCons. :(
--Cliff
Re: is it possible to mark buckets to be copied only when to be set-aside?
On Wed, 19 May 2004, Cliff Woolley wrote: can't just ignore APR_ENOTIMPL for bucket types, because pipe and socket buckets never had setaside implemented on them. I thought I remembered that that was because Greg and Ryan and I had some huge debate about it and it was decided for some reason that setting aside a pipe or socket didn't make sense. But now I can't find where we talked about that in the archives. BTW - I remembered the reason why it was decided that it didn't make sense to implement setaside for pipe/socket buckets. It's because for all other bucket types, setaside takes one bucket in and produces one bucket out, whereas for pipes and sockets it would take one bucket in and either produce one bucket if the lifetime request was already satisfied or it would produce a chain of n buckets out where n is proportional to the size of the data that had been waiting around to be read in the pipe/socket. It was that inconsistency that was disliked. At this point, I'm willing to agree to whatever makes things work and would probably accept this inconsistency as long as it's documented. What we have now is bug-prone beyond belief. --Cliff
