Re: httpmodule bug
I've gone into the code and the only thing I can image that occurs is that the web.config of one virtual directory is configured twice for the same AppDomain. Again, I'm curious, is one a child directory of another mount? Either physical or virtual path (or both?) I'm mounting the directory D:\Web\IssueTracker D:\Web isn't mounted, and both D:\Web and D:\ doesn't contain a web.config (no files at all actualy) Hmmm - so do you mean you have only one AspNetMount directive? If not I'm wondering - is one nested inside another? I was using 3 aspnetmount directives, all subdirectories of D:\Web (so D:\Web\), I've even removed two of the to test wether this makes any difference, but it doesn't. Somehow the web.config file of the site is configured multiple times. _ MSN Search, for accurate results! http://search.msn.nl
RE: httpmodule bug
Title: RE: httpmodule bug I wonder if that has to do with the fact that Apache reads the configuration file twice? Larry. -Original Message- From: Yussef Alkhamrichi [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 18, 2004 7:19 PM To: [EMAIL PROTECTED] Subject: Re: httpmodule bug I've gone into the code and the only thing I can image that occurs is that the web.config of one virtual directory is configured twice for the same AppDomain. Again, I'm curious, is one a child directory of another mount? Either physical or virtual path (or both?) I'm mounting the directory D:\Web\IssueTracker D:\Web isn't mounted, and both D:\Web and D:\ doesn't contain a web.config (no files at all actualy) Hmmm - so do you mean you have only one AspNetMount directive? If not I'm wondering - is one nested inside another? I was using 3 aspnetmount directives, all subdirectories of D:\Web (so D:\Web\), I've even removed two of the to test wether this makes any difference, but it doesn't. Somehow the web.config file of the site is configured multiple times. _ MSN Search, for accurate results! http://search.msn.nl
Re: [NOTICE] Subversion conversion
I say we move up. -sencer On Thu, 18 Nov 2004 16:37:16 -0600, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: CLI mod_aspdotnet folks; do we want to maintain httpd/cli/mod_aspdotnet/ or drop the cli/ container, placing all of our modules at the httpd/ root parallel to mod_mbox, mod_python, etc? I'm getting ready to move those as the incubator committee has graduated us! Bill
[NOTICE] CVS to SVN migration complete
Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. To check out your project: apache 1.3: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x \ apache-1.3 httpd 2.0: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x \ httpd-2.0 httpd 2.1: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/trunk \ httpd-2.1 httpd-test: $ svn co http://svn.apache.org/repos/asf/httpd/test/trunk \ httpd-test apreq: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/branches/1.x \ apreq apreq-2: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/trunk \ apreq-2 mod_python: $ svn co http://svn.apache.org/repos/asf/httpd/mod_python/trunk \ mod_python mod_mbox: $ svn co http://svn.apache.org/repos/asf/httpd/mod_mbox/trunk \ mod_mbox mod_pop3: $ svn co http://svn.apache.org/repos/asf/httpd/mod_pop3/trunk \ mod_pop3 httpd site: $ svn co http://svn.apache.org/repos/asf/httpd/site/trunk \ httpd-site Note that if you are a committer, you want to check out using https:// instead of http://. For further instructions on how to use SVN, I'll happily refer to: http://www.apache.org/dev/version-control.html Also note that there is one portion missing, which is the 1.3 documentation. We'll try to get around that ASAP. Once again, thanks for all your patience. I hope you feel it was worth the wait, Sander
Re: [NOTICE] CVS to SVN migration complete
At 01:13 PM 11/19/2004, Sander Striker wrote: Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. Committers will note their cvs diff of the now-locked repository will blow up for failure to create your lockfile... to rescue your deltas, use; cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic diff -u3 ../delta password is anoncvs Happy svn! Bill Bill
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
[EMAIL PROTECTED] wrote: Author: jorton Date: Fri Nov 19 02:27:41 2004 New Revision: 105803 Removed: httpd/test/trunk/perl-framework/.cvsignore httpd/test/trunk/perl-framework/Apache-Test/.cvsignore httpd/test/trunk/perl-framework/Apache-Test/lib/Apache/.cvsignore [...] Log: Remove .cvsignore files what's the replacement for .cvsignore under svn? I can't see where the data in .cvsignore has migrated to. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
what's the replacement for .cvsignore under svn? I can't see where the data in .cvsignore has migrated to. each directory now has properties and one of those properties is which files to ignore. see http://svnbook.red-bean.com/en/1.0/apas06.html for metadata info in general, http://svnbook.red-bean.com/en/1.0/ch07s02.html for property foo, specifically grep for svn:ignore. for other useful cvs to svn migration stuff http://svnbook.red-bean.com/en/1.0/apa.html is helpful if you haven't already seen it. for me, I've found this entirely unintuitive, since I can't seem to find a way to _add_ files to ignore without first gleaning which are currently ignored from .svn/. that is, since there seems to be no propadd option, I'm left with recreating .cvsignore from .svn/dir-props, adding the new file to ignore, then slurping up .cvsignore svn propset. and I always seem to cause some sort of conflict when I want to set properties on . instead of a directory below it. so, if anyone has any pointers here, that would be great :) --Geoff
Re: [NOTICE] CVS to SVN migration complete
On Fri, 19 Nov 2004, Sander Striker wrote: Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. Thanks so much for your hard work on this, and thanks in advance for answering all the stupid questions I'm sure to have as I get used to The New Way. -- When we are young, wandering the face of the earth, wondering what our dreams might be worth, learning that we're only immortal for a limited time.
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
Joe Orton wrote: On Fri, Nov 19, 2004 at 03:23:46PM -0500, Stas Bekman wrote: Geoffrey Young wrote: what's the replacement for .cvsignore under svn? I can't see where the data in .cvsignore has migrated to. each directory now has properties and one of those properties is which files to ignore. see Yes, but how do I see the change? I've seen Joe removing .cvsignore files. I have no idea whether he has added the properties for each of the removed files or not. The changes should be emailed no? The .cvsignore properties were automatically added into the svn:ignore properties by cvs2svn when the repos was converted, so when I removed the .cvsignore files that's all I did, nothing else needed tweaking. Great! so Geoff, that means you can drop the .cvsignore files in the mp2 tree I believe? When a propchange is committed a notification mail *will* be sent, but the post-commit script won't actually tell you the before-and-after in that case, it seems. I'm not sure whether that's a deficiency of the script being used or of SVN itself. You mean it only tells that there was a change, but not what was the change? if so who should be asked to fix that? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: svn commit: r105803 - etc
On Fri, Nov 19, 2004 at 04:21:31PM -0500, Stas Bekman wrote: Joe Orton wrote: When a propchange is committed a notification mail *will* be sent, but the post-commit script won't actually tell you the before-and-after in that case, it seems. I'm not sure whether that's a deficiency of the script being used or of SVN itself. You mean it only tells that there was a change, but not what was the change? if so who should be asked to fix that? http://marc.theaimsgroup.com/?l=apache-cvsm=110085589310749w=2 Looks that way, yup. infrastructure@ is who, I guess, if they're still awake ;)
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
The .cvsignore properties were automatically added into the svn:ignore properties by cvs2svn when the repos was converted, so when I removed the .cvsignore files that's all I did, nothing else needed tweaking. Great! so Geoff, that means you can drop the .cvsignore files in the mp2 tree I believe? done. --Geoff
CVS to SVN conversion
Hi again, The actual load seems to be working now (save the documentation...). Given that this wasn't a smooth ride, we've loaded things in the test repository. Please take a look at it: http://svn.apache.org/repos/test/httpd/ If noone raises any issues we'll load it in the main repository in 36 hours. Sander
Re: People still using v1.3 - finding out why
Hi, another reason may be mod_perl, althought mod_perl 2.0 is available for quite some time, and there is a good documentation how to migrate applications, many applications based on mod_perl haven't done so. The problem is not the same as for mod_php. mod_php 4.* has been available for apache 1.3 and apache 2 but mod_perl 1 only for apache 1 and mod_perl 2 only for apache 2. Mason(a mod_perl app) for eg. has mod_perl 2 support since 2004-10-18: -snip- As of Mason 1.27 (released 10/28/2004), there is support for Apache/mod_perl 2.0 in the core Mason code -snap- I have been using 2.0 since 2.0.35 but have damned our decision when serious breakage occured in mod_ssl in combination with various browsers and 3rd party ssl clients between version 2.0.46 and 2.0.49. 1.3, since I use it, never had those problems. Don't take me wrong, I like 2.0 and love it's features and the stability now is far better than when it was introduced, but I can understand people that call it too risky to migrate to 2.0. regards klaus
Re: RFC for a Perchild-like-MPM
Max Bowsher wrote: Quoting Ivan Ristic ivanr webkreator com (2004-11-17 17:31:39 GMT): I've used FastCGI to give individual users their own PHP engines (since PHP now comes with FastCGI protocol support built-in). This sounds useful - would you be willing to share some config file samples? Sure: --- LoadModule fastcgi_module modules/mod_fastcgi.so FastCgiWrapper /usr/local/apache/bin/suexec # This configuration will recycle persistent processes once every # 300 seconds, and make sure no processes run unless there is # a need for them to run. FastCgiConfig -singleThreshold 100 -minProcesses 0 -killInterval 300 NameVirtualHost * VirtualHost * ServerName ivanr.example.com DocumentRoot /home/ivanr/public_html SuexecUserGroup ivanr ivanr AddHandler application/x-httpd-php .php Action application/x-httpd-php /fastcgi-bin/php # this is a normal CGI folder Directory /home/ivanr/public_html/cgi-bin Options +ExecCGI SetHandler cgi-script /Directory Directory /home/ivanr/public_html/fastcgi-bin Options +ExecCGI SetHandler fastcgi-script /Directory /VirtualHost --- A copy of PHP that is FastCGI-aware should be placed at /home/ivanr/public_html/fastcgi-bin/php (compile PHP as CGI and --enable-fastcgi). PHP will tell you whether it understands FastCGI or not when invoked directly: # /home/ivanr/public_html/fastcgi-bin/php -v PHP 5.0.2 (cgi-fcgi) (built: Nov 19 2004 11:09:11) If a php.ini file is present in the same location it will be picked up automatically, thus allowing each user to configure their PHP instance as they're pleased. Once you get it up and running (suEXEC is a pain, as usual), tail the suexec log to make sure PHP is started only once, and that all subsequent invocations are handled by the persistent instance (obviously, nothing appears in the suexec log). -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: People still using v1.3 - finding out why
On Thu, 18 Nov 2004 13:43:17 -0600, Graham Leggett [EMAIL PROTECTED] wrote: Apart from backhand, are there in the experience of the people on this list any other significant apps out there that are keeping people from deploying httpd v2.x? The only complaint about functional regression I've heard from our user base in quite a while is disk caching proxy. (needs stable mod_disk_cache, where stable means something more than we just addressed a bunch of known issues, please go put it in production and let us know how many times your pager goes off ;) ) For the users I work with, it is rare that they depend on a third-party module which doesn't already support 2.0, and in fact there are a number of common situations where 2.0 is a better solution: If you were using server; 2.0, this issue wouldn't occur. (e.g., various resources both in core server and in key modules which are utilized much more efficiently with threaded server) If you were using server; 2.0, we could work around this problem as follows (e.g., implement small module utilizing 2.0 API features to work-around limitation of some other part of the system) With server; 2.0, feature A and feature B are not mutually exclusive. But it takes multiple occurrences of these situations over time before user will switch since the user needs to spend bulk of their time worrying about their applications instead of messing with the web server. So users with less interesting environments (problem situations are rare) remain on 1.3 much longer, while users with more interesting environments are predominantly on 2.0.
Re: PCRE in 2.1/2.2
On Wed, Nov 17, 2004 at 05:01:48PM -0800, Brian Pane wrote: About two years ago, I made some performance optimizations to the copy of pcre in the httpd-2.0 tree. I submitted the diffs to the pcre maintainer, but I don't know if they've made it into a subsequent pcre release. Yep, these have been in upstream releasessince pcre 4.0, with SMALL_NMATCH renamed to POSIX_MALLOC_THRESHOLD. joe
Re: CVS to SVN conversion
On Nov 17, 2004, at 4:45 PM, Sander Striker wrote: Hi again, The actual load seems to be working now (save the documentation...). Given that this wasn't a smooth ride, we've loaded things in the test repository. Please take a look at it: http://svn.apache.org/repos/test/httpd/ If noone raises any issues we'll load it in the main repository in 36 hours. I would like to publicly THANK Sander and Justin for their tireless (well, not literally tireless, because they worked so long that they were *very* tired) work in doing the conversion! I think during AC2004 everyone settled their beer scores, but Sander and Justin *definitely* are once again in the I owe you category :)
Directory proxy: fails to inherit per_dir_config on 1.3
I'm not sure whether this is a bug or a feature, but I've found myself
needing to combine ProxyPass with http authentication on a legacy Apache 1.3
box (which I'm unfortunately not in a position to upgrade to Apache 2 yet).
If I specify something like:
ProxyRequests off
ProxyPass / http://localhost:9998/
ProxyPassReverse / http://localhost:9998/
Directory proxy:http://localhost:9998
AuthType Basic
Limit GET POST
Order deny,allow
Deny from all
require group foobar
Satisfy Any
/Limit
/Directory
none of the Auth configuration from the Directory / of either the server's
base config or the enclosing vhost is inherited. This means that I have to
copy paste the rather extensive mod_*_auth config commands for each
proxied Directory and maintain them individually. I cannot include them
from a separate file as because dirsection() doesn't seem to follow Include
statements.
This seems wrong, especially as adding another Directory section along the
lines of
Directory proxy:http://localhost:9998/topsecret
AuthType Basic
Limit GET POST
Order deny,allow
Deny from all
require group admin
Satisfy Any
/Limit
/Directory
inherits the auth from the 'parent' proxy definition correctly.
I realise there is an inconsistency in how Directory proxy: would know
which non-special Directory sections to inherit from - it'd have to
crossreference the ProxyPass to see where the 'virtual' proxy paths would
sit on the real filesystem, and the whole thing is incompatible with the
idea of rewriting r-filename to be proxy:http://hostname/path internally
anyway.
However, all I want to do is inherit per_dir_config for the Directory
proxy: from the enclosing vhost or server root Directory, rather than the
default null config.
Alternatively, is there any way to juse use Directory /foo to set config
on the virtual directory /foo as exposed by the ProxyPass?
I've experimented a little in trying to merge the 'topmost' Directory
section's config into Directory proxy: sections:
diff -rup apache_1.3.33/src/main/http_config.c
apache_1.3.33-mjh/src/main/http_config.c
--- apache_1.3.33/src/main/http_config.c2004-11-19
15:43:37.0 +
+++ apache_1.3.33-mjh/src/main/http_config.c2004-11-19
15:42:40.0 +
@@ -1531,6 +1531,36 @@ static void fixup_virtual_hosts(pool *p,
ap_core_reorder_directories(p, main_server);
}
+
+static void fixup_proxypass_config(pool *p, server_rec *server)
+{
+core_server_config *sconf = ap_get_module_config(server-module_config,
+ core_module);
+void **sec = (void **) sconf-sec-elts;
+int num_sec = sconf-sec-nelts;
+int j;
+
+void *this_conf, *entry_config;
+core_dir_config *entry_core;
+
+for (j = 1; j num_sec; ++j) {
+
+entry_config = sec[j];
+entry_core = (core_dir_config *)
+ap_get_module_config(entry_config, core_module);
+
+if (!strncmp(entry_core-d, proxy:, 6)) {
+/* merge in config from the 'top-level' Directory section */
+entry_config = ap_merge_per_dir_configs(p,
+sec[0],
+entry_config
+);
+sec[j] = entry_config;
+}
+}
+}
+
+
/*
*
* Getting *everything* configured...
@@ -1639,6 +1669,7 @@ API_EXPORT(server_rec *) ap_read_config(
process_command_config(s, ap_server_post_read_config, p, ptemp);
fixup_virtual_hosts(p, s);
+fixup_proxypass_config(p, s);
default_listeners(p, s);
ap_fini_vhost_config(p, s);
but with no success - I'm not even sure if the API allows me to merge
per_dir_config in after the initial config pass, and before serving an
actual request.
Any insight would be hugely appreciated (and yes, I know how much nicer
proxying is in Apache 2 - if I had time to shift everything over, I would ;)
thanks,
Matthew.
--
__
Matthew Hodgson [EMAIL PROTECTED] Tel: +44 845 6667778
Systems Analyst, MX Telecom Ltd.
Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
Let's look at it this way. 2.1 is CTR whereas 2.0 is RTC. This applies to backports. However, the Review for most backports is already done within the 2.1 CTR cycle. If the original has been in 2.1 for a significant amount of time, it implies review. So the required review for that backport in 2.0 is pretty much mostly done. In other words, the R for 2.0 backports assumes that the CTR process in 2.1 is actually being done. This, I feel, should allow for some measurable leniency regarding backports in 2.0.
Re: RFC for a Perchild-like-MPM
Andrew Stribblehill, Thursday, November 18, 2004 07:53 Quoting Ivan Ristic [EMAIL PROTECTED] (2004-11-17 17:31:39 GMT): Paul Querna wrote: Are you familiar with FastCGI? My first impression is that most of what you envision is possible today with FastCGI, or would be possible with some (small) additional effort. FastCGI is non-free. This solution also copes with things like mod_php and mod_perl being a different user. A Good Thing IMO. Just to clarify: Which FastCGI are we talking about? There are two listed on http://modules.apache.org/ . There's the (former?) OpenMarket's http://fastcgi.com/ (mod_fastcgi), with the unclear license, which was last released as version 2.4.2 on 2003-11-24. Does it still work with Apache httpd 2.0.x? Does it work with 2.1.x? There's a more recent snapshot from 2004-04-14, but that is old enough to make me wonder about compatibility. Then there's http://fastcgi.coremail.cn/ (mod_fcgid), is GPL, which implements the FastCGI protocol, and was last released as version 1.0 on 2004-09-14. Is this implementation complete, efficient, comparable to the original mod_fastcgi? Leif
ErrorHeader directive and CHANGES
hi all...
we have the following entries in CHANGES under 2.1-dev:
*) Drop the ErrorHeader directive which turned out to be a misnomer.
Instead there's a new optional flag for the Header directive
('always'), which keeps the former ErrorHeader functionality.
[André Malo]
*) mod_headers: Allow 'echo' also for ErrorHeaders. [André Malo]
*) Bring ErrorHeader concept forward from 1.3, so that response
header fields can be set for return even on errors or external
redirects. [Ken Coar]
ErrorHeader appears to have been removed from the 2.0 branch as of 2.0.51.
I guess it depends on how you view CHANGES, but from my pov I would expect
it to just list tangible changes from, say, 2.0.53 to 2.2. since
ErrorHeader won't exist in 2.0.53 (or whatever the most recent release ends
up being) and won't exist in 2.2 maybe removing these from CHANGES
altogether is warranted?
I'm not sure if there are others like this as well, but if I have the chance
I'll scour CHANGES for a similar pattern.
--Geoff
Re: Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
At 05:41 PM 11/18/2004, Astrid Keßler wrote: IMHO a better way bring the development further is the suggestion on the dev list. *absolute* feature freeze on stable branches (except 1.3?), bug fixes only. Though it would need some time to establish the trust of the community in so much more versions, I like that idea somehow. +1 My opinion on feature freeze is that while 2.odd-dev is murky, there may be cause to add reasonable features to 2.even provided they have ***no*** impact on existing, configured 2.even.prior installs. Once a 2.odd-dev graduates to 2.odd-alpha, then 2.odd-beta, we should be ready to put the icing on the next 2.even. At -that- point, once we release (or have nearly released) the new 2.even, the old 2.even should be at near-absolute-zero feature freeze. Just IMHO - feel free to debate. Additionally, let's do 2.1 tarballs to bring the current development branch to a wider group of devs and testers. Without any question - it's problem number one.
Syncing access to socreboard
Hi, Does anyone has idea how to protect the access to the scoreboard? Does apache 2.1 has some global lock that can be used for that (with public api perhaps)? Regards, Mladen.
Re: RFC for a Perchild-like-MPM
Leif W wrote: Andrew Stribblehill, Thursday, November 18, 2004 07:53 Quoting Ivan Ristic [EMAIL PROTECTED] (2004-11-17 17:31:39 GMT): Paul Querna wrote: Are you familiar with FastCGI? My first impression is that most of what you envision is possible today with FastCGI, or would be possible with some (small) additional effort. FastCGI is non-free. This solution also copes with things like mod_php and mod_perl being a different user. A Good Thing IMO. Just to clarify: Which FastCGI are we talking about? There are two listed on http://modules.apache.org/ . There's the (former?) OpenMarket's http://fastcgi.com/ (mod_fastcgi), with the unclear license, In what sense is the licence unclear? But even if it is, I think it is worth to reuse the protocol alone. There are many well-tested FastCGI libraries that support it on the client side. If the general idea of using FastCGI is acceptable a stress test can be performed to determine whether the performance of the existing modules/libraries is adequate. which was last released as version 2.4.2 on 2003-11-24. Does it still work with Apache httpd 2.0.x? Works fine with httpd 2.0.x in my tests (mod_fastcgi 2.4.2, I didn't try the more recent snapshot). I have the impression that many people feel FastCGI is dead because there isn't much activity on the web site. But it seems to me the authors have just made the protocol (and the Apache module) do what they wanted it to do. Does it work with 2.1.x? I don't know. Then there's http://fastcgi.coremail.cn/ (mod_fcgid), is GPL, which implements the FastCGI protocol, and was last released as version 1.0 on 2004-09-14. Is this implementation complete, efficient, comparable to the original mod_fastcgi? Never used that one. The web site does not say what motivated the developer to produce another implementation. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: ErrorHeader directive and CHANGES
* Geoffrey Young [EMAIL PROTECTED] wrote:
we have the following entries in CHANGES under 2.1-dev:
*) Drop the ErrorHeader directive which turned out to be a misnomer.
Instead there's a new optional flag for the Header directive
('always'), which keeps the former ErrorHeader functionality.
[André Malo]
*) mod_headers: Allow 'echo' also for ErrorHeaders. [André Malo]
*) Bring ErrorHeader concept forward from 1.3, so that response
header fields can be set for return even on errors or external
redirects. [Ken Coar]
ErrorHeader appears to have been removed from the 2.0 branch as of 2.0.51.
I guess it depends on how you view CHANGES, but from my pov I would expect
it to just list tangible changes from, say, 2.0.53 to 2.2. since
ErrorHeader won't exist in 2.0.53 (or whatever the most recent release ends
up being) and won't exist in 2.2 maybe removing these from CHANGES
altogether is warranted?
In this case, I think, no. It's clearly stated in 2.0, that's a backport from
the development branch (since it were different changes to the code base).
In most cases it *was* removed from 2.1 change log.
nd
--
Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: CVS to SVN conversion
* Jim Jagielski [EMAIL PROTECTED] wrote: I would like to publicly THANK Sander and Justin for their tireless (well, not literally tireless, because they worked so long that they were *very* tired) work in doing the conversion! I think during AC2004 everyone settled their beer scores, but Sander and Justin *definitely* are once again in the I owe you category :) ACK! nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: CVS to SVN conversion
* Sander Striker [EMAIL PROTECTED] wrote: Hi again, The actual load seems to be working now (save the documentation...). Given that this wasn't a smooth ride, we've loaded things in the test repository. Please take a look at it: http://svn.apache.org/repos/test/httpd/ If noone raises any issues we'll load it in the main repository in 36 hours. Looks basically fine. I'm wondering a bit about the tags directory, especially the 1.3 subdir. Is it necessary, is there something broken? nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
Re: CVS to SVN conversion
--On Friday, November 19, 2004 7:57 PM +0100 André Malo [EMAIL PROTECTED] wrote: Looks basically fine. I'm wondering a bit about the tags directory, especially the 1.3 subdir. Is it necessary, is there something broken? Just to be clear, Sander's email that you are replying to was an artifact of the busted network at Alexis Park. The conversion is now complete and live at: http://svn.apache.org/repos/asf/httpd/ Sander should be following up with detailed instructions soon-ish. But, alas, I think he fell asleep at the keyboard once again this morning. ;-) Regarding the tags/1.3 subdir, those are the complete tags for the 1.3 series. Our conversion got royally messed up due to the docs files as they contain overlapping tags with the 1.3 repository. So, I've cleared out most of the bogus tags in the tags/ directory and I need to move all of the 'real' 1.3 tags into the tags/ dir. I hope that makes some sense - if not, take a look at the repository in about 24-48 hours and it'll make more sense... =) -- justin
RE: People still using v1.3 - finding out why
We continue to have 1.3 servers because the Enhydra Director module, needed for Enydra Application Server version 3, has not been ported to Apache 2. The reason is that the Enhydra folks have long since abandoned the protocol and now use AJP13, for which there is already mod_jk2 and the AJP13 proxy in 2.1. The obvious solution is to either upgrade Enhydra to a newer version or move to another app server. We decided to move to another app server, but it's a lengthy process when you have 100's of applications written for the old app server. To combat the problem, I wrote a patch for Apache 2 to do session cookie based load balancing in combination with rewrite rules (which I submitted long ago to this group- but I think it becomes moot in Apache 2.2) and have written scripts which convert our enhydra director config files over to a set of proxy rewrite rules- so we are attempting to use the HTTP connector of the enhydra app server. This has a set of its own problems- like applications which depend on API's to return the remote host IP or bugs in the HTTP connector implementation (ie, lack of URL decoding...) So enhydra director is the reason we've not been able to dump Apache 1.3; but we have plans to work around our issues and gradually continue to move to Apache 2. Byron -Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 2:43 PM To: [EMAIL PROTECTED] Subject: People still using v1.3 - finding out why Hi all, I've been keen to do some digging for reasons why someone might need to install httpd v1.3 instead of v2.0 or later. Support for mod_backhand seems to be a significant reason (and getting backhand ported to v2.0 would be a win): Apart from backhand, are there in the experience of the people on this list any other significant apps out there that are keeping people from deploying httpd v2.x? Regards, Graham --
[NOTICE] CVS to SVN migration complete
Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. To check out your project: apache 1.3: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x \ apache-1.3 httpd 2.0: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x \ httpd-2.0 httpd 2.1: $ svn co http://svn.apache.org/repos/asf/httpd/httpd/trunk \ httpd-2.1 httpd-test: $ svn co http://svn.apache.org/repos/asf/httpd/test/trunk \ httpd-test apreq: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/branches/1.x \ apreq apreq-2: $ svn co http://svn.apache.org/repos/asf/httpd/apreq/trunk \ apreq-2 mod_python: $ svn co http://svn.apache.org/repos/asf/httpd/mod_python/trunk \ mod_python mod_mbox: $ svn co http://svn.apache.org/repos/asf/httpd/mod_mbox/trunk \ mod_mbox mod_pop3: $ svn co http://svn.apache.org/repos/asf/httpd/mod_pop3/trunk \ mod_pop3 httpd site: $ svn co http://svn.apache.org/repos/asf/httpd/site/trunk \ httpd-site Note that if you are a committer, you want to check out using https:// instead of http://. For further instructions on how to use SVN, I'll happily refer to: http://www.apache.org/dev/version-control.html Also note that there is one portion missing, which is the 1.3 documentation. We'll try to get around that ASAP. Once again, thanks for all your patience. I hope you feel it was worth the wait, Sander
Re: CVS to SVN conversion
On Fri, 2004-11-19 at 11:04, Justin Erenkrantz wrote: --On Friday, November 19, 2004 7:57 PM +0100 André Malo [EMAIL PROTECTED] wrote: Looks basically fine. I'm wondering a bit about the tags directory, especially the 1.3 subdir. Is it necessary, is there something broken? Just to be clear, Sander's email that you are replying to was an artifact of the busted network at Alexis Park. Indeed, others will find they have received 'out-of-date' mail from me as well. The conversion is now complete and live at: http://svn.apache.org/repos/asf/httpd/ Sander should be following up with detailed instructions soon-ish. But, alas, I think he fell asleep at the keyboard once again this morning. ;-) *blush* The instructions ended up not to be so detailed, but hey :) Regarding the tags/1.3 subdir, those are the complete tags for the 1.3 series. Our conversion got royally messed up due to the docs files as they contain overlapping tags with the 1.3 repository. So, I've cleared out most of the bogus tags in the tags/ directory and I need to move all of the 'real' 1.3 tags into the tags/ dir. Thanks again Justin, Sander
Re: People still using v1.3 - finding out why
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. Peter
SVN usage, log message policy
Hi guys, Now that we are using SVN, would we want to adopt a guideline for log messages. The SVN project itself uses a standard format for all their log messages and I must say that it has helped me tremendously when doing reviews. See http://svn.collab.net/repos/svn/HACKING for details (look for Writing log messages). I reckomend reading the entire document, since I think it has more useful ideas than just providing a guideline on log messages. Sander PS. I'll most likely be offline for the entire upcoming week, in case you wonder why I don't contribute to the resulting thread.
Re: [NOTICE] CVS to SVN migration complete
At 01:13 PM 11/19/2004, Sander Striker wrote: Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. Committers will note their cvs diff of the now-locked repository will blow up for failure to create your lockfile... to rescue your deltas, use; cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic diff -u3 ../delta password is anoncvs Happy svn! Bill Bill
Re: ErrorHeader directive and CHANGES
In this case, I think, no. It's clearly stated in 2.0, that's a backport from the development branch (since it were different changes to the code base). ok. it still feels a little strange to talk about something that was both (re)added and removed between releases, since the net change is no change for the end user, but I'm cool with it :) In most cases it *was* removed from 2.1 change log. :) --Geoff
Re: SVN usage, log message policy
http://svn.collab.net/repos/svn/trunk/HACKING At 01:24 PM 11/19/2004, Sander Striker wrote: Hi guys, Now that we are using SVN, would we want to adopt a guideline for log messages. The SVN project itself uses a standard format for all their log messages and I must say that it has helped me tremendously when doing reviews. See http://svn.collab.net/repos/svn/HACKING for details (look for Writing log messages). I reckomend reading the entire document, since I think it has more useful ideas than just providing a guideline on log messages. Sander PS. I'll most likely be offline for the entire upcoming week, in case you wonder why I don't contribute to the resulting thread.
mod_rewrite functional patch
Hi, I recently installed MediaWiki [1] (as used and developed on/by WikiPedia [2]). This wiki software allows an intuitive use of URLs as long as the host admin has patched his apache to allow the proper rewrite rules [3]. As Gentoo is about to support this software, we cannot expect every host admin to patch their installed apache software by hand (not everyone knows how to do this). MediaWiki officially provides a patch for apache 1.3.x. Since the development goes towards 2.0 (and 2.1) I adapted the patch to 2.0 [4]. I actually put this patch to our patchset of apache 2.0 wich will be soon available to the main users. However, keeping track on patches each new release makes no fun at all, also, this new functionality introduced by MediaWiki to mod_rewrite is a general purpose function. Though, I'd like to request you to commit this patch [4] to HEAD, so, that it can be available by upstream from apache 2.1 and later. Best Regards, Christian Parpart. p.s.: that patch is just about 50 lines, it's trivial and shouldn't make any problems though. [1] http://www.mediawiki.org/ [2] http://www.wikipedia.org/ [3] http://meta.wikimedia.org/wiki/Rewrite_Rules#httpd.conf [4] http://dev.gentoo.org/~trapni/dist/06_all_mod_rewrite_ampescape.patch -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 21:25:00 up 21 days, 13:54, 2 users, load average: 0.88, 0.87, 0.82 pgpTFbaEW7RJR.pgp Description: PGP signature
Re: mod_rewrite functional patch
* Christian Parpart [EMAIL PROTECTED] wrote: I recently installed MediaWiki [1] (as used and developed on/by WikiPedia [2]). This wiki software allows an intuitive use of URLs as long as the host admin has patched his apache to allow the proper rewrite rules [3]. As Gentoo is about to support this software, we cannot expect every host admin to patch their installed apache software by hand (not everyone knows how to do this). MediaWiki officially provides a patch for apache 1.3.x. Since the development goes towards 2.0 (and 2.1) I adapted the patch to 2.0 [4]. Actually you don't need to patch httpd-2.0 for *that*. You can write a small module, which registers the mapper function at runtime. I can help you, if you like (I'm a happy Gentoo user, though I'm naturally using my own httpd ebuild ;-)) However, I think, the map is way too special for common inclusion. A better way would be to provide a general replace map (starting with 2.1, I'd suggest). For 2.0 releases the small support module should be enough. How does this sound? nd -- [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet? DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da so reinpacken und dann absolut positionieren ... -- Florian Hartig und Lars Kasper in dciwam
More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see trunk which could be any one of a number of files. Not all of which I am interested in. Personally I would opt for file listings rather than directory listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. Thanks again for all of your hard work. Brad Justin Erenkrantz [EMAIL PROTECTED] Friday, November 19, 2004 12:12:39 PM --On Friday, November 19, 2004 11:11 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Our CVS mailer only showed the last directory (with files) that was committed - so subject lines were *always* inaccurate when touching multiple directories. The SVN mailer always shows all directories that were modified. I think that's a far better compromise. Plus, we've received a number of complaints that the subject lines were too long to be useful: hence just the directory names. *shrug* -- justin
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
--On Friday, November 19, 2004 2:41 PM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. IMHO, the revision number is the *most* important attribute of the commit. Subversion uses global revision numbers: there is no per-file revisions like CVS. If you know the revision number, you can get everything else. And, we already had a 'cvs commit: ' prefix on our previous CVS emails. -- justin
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I understand about the revision numbers and I agree that it is an important piece of information, but unnecessary on the subject line. The subject line needs to include information that allows one to quickly sort and prioritize the commits. IMHO, the revision number isn't a piece of information that helps do that. Once I have determined that the commit is important enough for me to review, I will certainly open and view the contents of the message. After I have reviewed the commit via the message contents and determined that further review is necessary, that is the point when the revision number becomes *very* important. As far as the svn commit: prefix is concerned, it was redundant information before and I believe that it is still redundant information. Perhaps svn: is all that would be required so that when a commit message is replied to on the dev@ lists, it is distinguished from other posts. Brad [EMAIL PROTECTED] Friday, November 19, 2004 2:47:17 PM --On Friday, November 19, 2004 2:41 PM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. IMHO, the revision number is the *most* important attribute of the commit. Subversion uses global revision numbers: there is no per-file revisions like CVS. If you know the revision number, you can get everything else. And, we already had a 'cvs commit: ' prefix on our previous CVS emails. -- justin
Re: mod_rewrite functional patch
On Friday 19 November 2004 10:36 pm, André Malo wrote: * Christian Parpart [EMAIL PROTECTED] wrote: I recently installed MediaWiki [1] (as used and developed on/by WikiPedia [2]). This wiki software allows an intuitive use of URLs as long as the host admin has patched his apache to allow the proper rewrite rules [3]. As Gentoo is about to support this software, we cannot expect every host admin to patch their installed apache software by hand (not everyone knows how to do this). MediaWiki officially provides a patch for apache 1.3.x. Since the development goes towards 2.0 (and 2.1) I adapted the patch to 2.0 [4]. Actually you don't need to patch httpd-2.0 for *that*. You can write a small module, which registers the mapper function at runtime. This is a way to much overhead, just for this function, isn't it? I can help you, if you like that would be great. (see below) (I'm a happy Gentoo user, though I'm naturally using my own httpd ebuild ;-)) *heh*... however, it's not really nice (personally) to read, that you're using your own ebuild. I hope the next ebuild updates in future (mid december) will change your mind ;-) However, I think, the map is way too special for common inclusion. A better way would be to provide a general replace map (starting with 2.1, I'd suggest). For 2.0 releases the small support module should be enough. How does this sound? That replace map sounds great to me. this would fill the requirements for MediaWiki (easily) and could be use for more general purposes as well. However, I fear a bit for the syntax to be used in httpd.conf then since I'm not that creative ATM. I submitted a patch in [1] just before I read your mail. I'm willing to spend some time tonight to write that module - but I'll maybe need some help anyway. lets see. Regards, Christian Parpart. -- http://www.winterschur.de/?fey -- help me to get a sheep! 23:24:18 up 21 days, 15:54, 0 users, load average: 0.95, 1.19, 1.15 pgpcnsTB8Lrau.pgp Description: PGP signature
Re: RFC for a Perchild-like-MPM
Ivan Ristic, Friday, November 19, 2004 12:42 Leif W wrote: Andrew Stribblehill, Thursday, November 18, 2004 07:53 Quoting Ivan Ristic [EMAIL PROTECTED] (2004-11-17 17:31:39 GMT): Paul Querna wrote: Are you familiar with FastCGI? My first impression is that most of what you envision is possible today with FastCGI, or would be possible with some (small) additional effort. FastCGI is non-free. This solution also copes with things like mod_php and mod_perl being a different user. A Good Thing IMO. Just to clarify: Which FastCGI are we talking about? There are two listed on http://modules.apache.org/ . There's the (former?) OpenMarket's http://fastcgi.com/ (mod_fastcgi), with the unclear license, In what sense is the licence unclear? Unclear in the sense that one person said it wasn't free, and another person said it was ASF compliant, and I couldn't tell the difference after skimming the license quickly. It wasn't abundantly clear at first, so I wasn't making any conclusions. Also in the sense of how it can be used. Free or not, modify or not, incorporate in other things, redistribute incorporated binaries from modified or unmodified sources. The business about using it only for FastCGI implementations is a potential trouble spot. What if someone wanted to make some hybrid module. I'm not a module developer at this point,so I don't know if or when it would make sense to do such a thing. But if I have a fork in one hand and a electrical outlet in the other, I want the right to electrocute myself and see what happens. :) But even if it is, I think it is worth to reuse the protocol alone. There are many well-tested FastCGI libraries that support it on the client side. After skimming the home page, there seemed to be a clear distinction between the code for the module and the protocol specification, where the module code is a reference implementation of the FastCGI protocol. That was my impression. which was last released as version 2.4.2 on 2003-11-24. Does it still work with Apache httpd 2.0.x? Works fine with httpd 2.0.x in my tests (mod_fastcgi 2.4.2, I didn't try the more recent snapshot). I have the impression that many people feel FastCGI is dead because there isn't much activity on the web site. But it seems to me the authors have just made the protocol (and the Apache module) do what they wanted it to do. It was my impression that it was probably dead, and as you said, possibly just complete or working, which seems like such an alien concept in free software, where changes and activity are like heartbeats and a pulse. :) Does it work with 2.1.x? I don't know. When I have time I might try 2.1 from the new shiny SVN. Then there's http://fastcgi.coremail.cn/ (mod_fcgid), is GPL, which implements the FastCGI protocol, and was last released as version 1.0 on 2004-09-14. Is this implementation complete, efficient, comparable to the original mod_fastcgi? Never used that one. The web site does not say what motivated the developer to produce another implementation. More toys to play with. We now return to our regularly scheduled thread, already in progress. Leif
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
Brad Nicholes wrote: I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see trunk which could be any one of a number of files. Not all of which I am interested in. Personally I would opt for file listings rather than directory listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. I agree with Brad. Also what kind of usability one finds to get a 10 lines and more long Subject? Here is an example of a recent commit. Subject: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules I think it'll be more useful to have the following Subject format: $id $first_subdir/$first_file ($trunk) in the example above (where only dirs were affected): Subject: r105803 . (httpd/test/trunk/perl-framework) If there was a file changed, e.g. Apache-Test/README Subject: r105803 Apache-Test/README (httpd/test/trunk/perl-framework) if you wish to retain 'svn' prefix, that's fine, but there is need to waste space with 'svn commit'. e.g.: Subject: svn r105803 Apache-Test/README (httpd/test/trunk/perl-framework) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Event MPM - CLOSE_WAITs
I have Paul's version of the Event MPM patch up and running. The only glitch I
saw bringing it up was a warning for two unused variables in http_core.c
(patchlet below). Then I tried stressing it with SPECweb99 and saw some errors
after several minutes:
[error] (24)Too many open files: apr_socket_accept: (client socket)
...and a few others with the same errno. Digging into it a bit, sockets are
hanging around with netstat showing an abnormally high number of CLOSE_WAITs.
We must be missing a close() somewhere. Maybe in the timeout logic? I believe
that was reworked.
If no one beats me to it and day job permitting, I'll investigate further next
week.
Greg
--- modules/http/http_core.c.orig 2004-11-17 14:15:26.704770352 -0500
+++ modules/http/http_core.c2004-11-17 14:16:35.009770200 -0500
@@ -234,8 +234,6 @@
static int ap_process_http_async_connection(conn_rec *c)
{
request_rec *r;
-int csd_set = 0;
-apr_socket_t *csd = NULL;
conn_state_t *cs = c-cs;
switch (cs-state) {
Re: mod_rewrite functional patch
* Christian Parpart [EMAIL PROTECTED] wrote:
Actually you don't need to patch httpd-2.0 for *that*. You can write a
small module, which registers the mapper function at runtime.
This is a way to much overhead, just for this function, isn't it?
Given the fact, that the 2.0 architecture is built for such extensions -
not much. And compared to the effort of maintaining a patch... ;-)
(I'm a happy Gentoo user, though I'm naturally using my
own httpd ebuild ;-))
*heh*... however, it's not really nice (personally) to read, that you're
using your own ebuild. I hope the next ebuild updates in future (mid
december) will change your mind ;-)
Probably not. I'm using some own patches, different config scheme, etc., but
I'll look at it from time to time to see what happens to the httpd :)
However, I think, the map is way too special for common inclusion. A
better way would be to provide a general replace map (starting with 2.1,
I'd suggest). For 2.0 releases the small support module should be enough.
How does this sound?
That replace map sounds great to me. this would fill the requirements for
MediaWiki (easily) and could be use for more general purposes as well.
However, I fear a bit for the syntax to be used in httpd.conf then since I'm
not that creative ATM.
Something like:
RewriteMap replace int:replace
RewriteRule (.*) ${replace:x|y}
'misusing' the default value, which isn't even needed in that case. Though
this would require some more code changes in mod_rewrite (passing the default
value to the map), this sounds like a good idea to me - and should not be in
2.0.
I submitted a patch in [1] just before I read your mail. I'm willing to
spend some time tonight to write that module - but I'll maybe need some help
anyway. lets see.
No problem. It reminds (e.g. me) that there's something open ;)
nd
--
Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)
-- aus einer Rezension
http://pub.perlig.de/books.html#apache2
Re: Event MPM - CLOSE_WAITs
Greg Ames wrote: I have Paul's version of the Event MPM patch up and running. The only glitch I saw bringing it up was a warning for two unused variables in http_core.c (patchlet below). Then I tried stressing it with SPECweb99 and saw some errors after several minutes: [error] (24)Too many open files: apr_socket_accept: (client socket) Need to bump your ulimits. I ran into this too. After raising it to 4096 open FDs per process, I didn't have any issues. (Linux default is 1024?) ...and a few others with the same errno. Digging into it a bit, sockets are hanging around with netstat showing an abnormally high number of CLOSE_WAITs. We must be missing a close() somewhere. Maybe in the timeout logic? I believe that was reworked. If no one beats me to it and day job permitting, I'll investigate further next week. I am planning to commit the Event MPM to svn in a few minutes :) Thanks for the patch! -Paul
Re: [NOTICE] CVS to SVN migration complete
* Sander Striker [EMAIL PROTECTED] wrote: Hi everyone, The CVS to SVN conversion of the Apache HTTP Server projects is complete. Just a question: Maybe I'm missing the info - is the httpd trunk supposed to work with the apr 1.0.x branch or just the apr trunk? nd -- die (eval q-qq:Just Another Perl Hacker :-) # André Malo, http://pub.perlig.de/ #
Re: [NOTICE] CVS to SVN migration complete
--On Saturday, November 20, 2004 1:49 AM +0100 André Malo [EMAIL PROTECTED] wrote: Just a question: Maybe I'm missing the info - is the httpd trunk supposed to work with the apr 1.0.x branch or just the apr trunk? We're going to have to decide which APR branch/release httpd 2.1/2.2 should work with - and, we'll have to decide soon. Whichever we pick, we need to stick 2.2 to a *released* version of APR. At this point, without a compelling argument, I'd vote for 1.0.x. -- justin
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I happen to agree that the commit messages suck, but the right thing to do is have a look at the script and suggest a patch on the infrastructure mailing list. I would do it myself, but have a paper to write first. I also think that placement of the Log text after the long list of files is obviously broken, and the commit template does not include prefixes for Submitted by: Reviewed by: Obtained from: which are really really important. I don't think that this discussion belongs on every mailing list that uses subversion -- move it to infrastructure. Roy
Re: [NOTICE] CVS to SVN migration complete
At 06:52 PM 11/19/2004, Justin Erenkrantz wrote: --On Saturday, November 20, 2004 1:49 AM +0100 André Malo [EMAIL PROTECTED] wrote: Just a question: Maybe I'm missing the info - is the httpd trunk supposed to work with the apr 1.0.x branch or just the apr trunk? We're going to have to decide which APR branch/release httpd 2.1/2.2 should work with - and, we'll have to decide soon. Whichever we pick, we need to stick 2.2 to a *released* version of APR. At this point, without a compelling argument, I'd vote for 1.0.x. -- justin I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. That is the right answer, branch APR 1.x, fix on svn trunk (2.0.0) and commit the right code in httpd-2.2 such that an allocation of memory is consistently size_t and an allocation of disk is consistently off_t, and none of which has anything to do with int or long. Bill
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
--On Friday, November 19, 2004 6:22 PM -0800 Roy T. Fielding [EMAIL PROTECTED] wrote: I happen to agree that the commit messages suck, but the right thing to do is have a look at the script and suggest a patch on the infrastructure mailing list. I would do it myself, but have a paper http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/mailer/ See mailer.py. the long list of files is obviously broken, and the commit template does not include prefixes for Submitted by: Reviewed by: Obtained from: which are really really important. We'd probably need to do work on enhancements for this. -- justin
2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
--On Friday, November 19, 2004 8:01 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. That is the right answer, branch APR 1.x, fix on svn trunk (2.0.0) and commit the right code in httpd-2.2 such that an allocation of memory is consistently size_t and an allocation of disk is consistently off_t, and none of which has anything to do with int or long. I don't believe that Allen would be able to complete his changes in a reasonable timeframe. I'm tired of holding things up for a 'major' rewrite that'll come any day now (TM). Sorry. I'd be willing to give him a week or two to make the changes everywhere he needs to, but even then it'd be hard for all of us to review such a major change. I'm in favor of releasing httpd 2.1 as 2.2 almost as-is with some relatively minor things thrown in (say the config re-org changes and the group hooks). However, trying to fix the 64-bit issues in a 2.2 (and with an APR 2.0) at this late state would make it really hard for our module writers to adopt 2.2 in a timely manner. So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote: --On Friday, November 19, 2004 8:01 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. I don't believe that Allen would be able to complete his changes in a reasonable timeframe. So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- I guess the ball is to Allen, then, but I'd also be happy to quickly whack at it. The concept is Simple(tm) and would be far less painful than actually fighting through all the ( cast )s of his later patches. Bill
2.1.1 tarballs posted...
http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin
Re: 2.1.1 tarballs posted...
Justin Erenkrantz wrote: http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin +1 for beta. Tested on FreeBSD 5.2.1 and Linux 2.6.
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
Re: 2.1.1 tarballs posted...
At 12:14 AM 11/20/2004, Justin Erenkrantz wrote: http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin 2.1.1 is nothing (yet) 3 +1's (more +1 than -1) becomes alpha release. 3 +1's (more +1 than -1) alpha becomes beta. That beta becomes a perfect branch point for 2.2 GA. Bill
Re: 2.1.1 tarballs posted...
--On Saturday, November 20, 2004 12:53 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: 2.1.1 is nothing (yet) 3 +1's (more +1 than -1) becomes alpha release. 3 +1's (more +1 than -1) alpha becomes beta. That beta becomes a perfect branch point for 2.2 GA. Not quite. It's alpha now. See http://httpd.apache.org/dev/release.html: Alpha indicates that the release is not meant for mainstream usage or may have serious problems that prohibits its use. When a release is initially created, it automatically becomes alpha quality. blows dust off release procedures The progression is alpha-beta-GA with it initially being alpha. Beta means that 3 people have looked at it and approved it. I know it's been a while since we've done an unstable release, but 2.1.1 is alpha. =) -- justin
Re: 2.1.1 tarballs posted...
At 01:22 AM 11/20/2004, Justin Erenkrantz wrote: --On Saturday, November 20, 2004 12:53 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Alpha indicates that the release is not meant for mainstream usage or may have serious problems that prohibits its use. When a release is initially created, it automatically becomes alpha quality. blows dust off release procedures Back up. Nothing is a release, not even an alpha, without 3 +1's. Until it's voted as a release, even as alpha, it's simply a tarball. Nobody can declare any release without 3 +1's and it's been that way for about 7 years. Bill
