RE: [NOTICE] Subversion conversion
Title: RE: [NOTICE] Subversion conversion Sweet! I would vote to move it up one level. Thanks, Larry. -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 18, 2004 5:37 PM To: CLI Dev Subject: Re: [NOTICE] Subversion conversion 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 At 12:52 AM 11/18/2004, Justin Erenkrantz wrote: --On Saturday, November 13, 2004 7:03 PM -0600 Sander Striker [EMAIL PROTECTED] wrote: I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I'm shooting for being done with it all by tomorrow night. Heh. Best laid plans of mice and men. =) Anyhow, we've finally got the conversion finished. We're going to ask for one final sanity check from the community before we load it into the real repository. Unless we stumble upon something major in the next 12-24 hours, I will load it in and open the trees back up. You can browse/checkout the repository at: http://svn.apache.org/repos/test/ When we go live, this dump will be loaded into the asf repository under httpd. (So, httpd-2.0 will be in httpd/httpd/trunk.) Note that *no* modifications made to the test repository will be preserved. The httpd-docs-1.3 repository still needs to be merged in. (The way our httpd-1.3-docs is handled causes all sorts of nightmares with httpd-2.0's copies of the RCS files.) I plan on tackling that tomorrow, but I have to get a few other backroom things resolved (mailer and ACLs) before loading the repository first anyhow. Thanks for everyone's patience! -- justin
Re: httpmodule bug
At 04:52 PM 11/18/2004, Yussef Alkhamrichi wrote: 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? Bill
[STATUS] (flood) Wed Nov 17 23:46:17 EST 2004
flood STATUS: -*-text-*- Last modified at [$Date: 2003/07/01 20:55:12 $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * More analysis and graphing scripts are needed * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. Jacek is working on a Mozilla application, codename Flood URL bag (much like Live HTTP Headers) and small HTTP proxy. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is called easy reports (see flood_easy_reports.h). Furthermore,
Re: RFC for a Perchild-like-MPM
Quoting Ivan Ristic [EMAIL PROTECTED] (2004-11-17 17:31:39 GMT): Paul Querna wrote: I have had an idea for replacing the perchild MPM boggling around inside my head for awhile now. This is an idea for a different architecture to allowing different UIDs to serve httpd requests. I am looking for all feedback with my proposed approach. 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 comes with a process manager that can be configured to start server processes on demand. Server processes can work as different uids (through suEXEC). I've used FastCGI to give individual users their own PHP engines (since PHP now comes with FastCGI protocol support built-in). I think the only part missing right now is the ability to compile Apache to function as a FastCGI client, and accept requests over FastCGI instead of HTTP. That can be a full version of Apache, or a slimmed-down version (e.g. with no input/output filters). FastCGI is non-free. This solution also copes with things like mod_php and mod_perl being a different user. A Good Thing IMO. -- VIKING NORTH UTSIRE SOUTH UTSIRE NORTHWEST 6 OR 7, OCCASIONALLY GALE 8 AT FIRST. WINTRY SHOWERS. GOOD OCCASIONALLY MODERATE OR POOR
Re: RFC for a Perchild-like-MPM
Andrew Stribblehill wrote: Quoting Ivan Ristic [EMAIL PROTECTED] (2004-11-17 17:31:39 GMT): Paul Querna wrote: I have had an idea for replacing the perchild MPM boggling around inside my head for awhile now. This is an idea for a different architecture to allowing different UIDs to serve httpd requests. I am looking for all feedback with my proposed approach. 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 comes with a process manager that can be configured to start server processes on demand. Server processes can work as different uids (through suEXEC). I've used FastCGI to give individual users their own PHP engines (since PHP now comes with FastCGI protocol support built-in). I think the only part missing right now is the ability to compile Apache to function as a FastCGI client, and accept requests over FastCGI instead of HTTP. That can be a full version of Apache, or a slimmed-down version (e.g. with no input/output filters). FastCGI is non-free. This solution also copes with things like mod_php and mod_perl being a different user. A Good Thing IMO. Below is the licence included in the distribution. The way I read it it's compatible with the Apache licence. --- This FastCGI application library source and object code (the Software) and its documentation (the Documentation) are copyrighted by Open Market, Inc (Open Market). The following terms apply to all files associated with the Software and Documentation unless explicitly disclaimed in individual files. Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here. If modifications to this Software and Documentation have new licensing terms, the new terms must be clearly indicated on the first page of each file where they apply. OPEN MARKET MAKES NO EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE SOFTWARE OR THE DOCUMENTATION, INCLUDING WITHOUT LIMITATION ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL OPEN MARKET BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY DAMAGES ARISING FROM OR RELATING TO THIS SOFTWARE OR THE DOCUMENTATION, INCLUDING, WITHOUT LIMITATION, ANY INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES OR SIMILAR DAMAGES, INCLUDING LOST PROFITS OR LOST DATA, EVEN IF OPEN MARKET HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED AS IS. OPEN MARKET HAS NO LIABILITY IN CONTRACT, TORT, NEGLIGENCE OR OTHERWISE ARISING OUT OF THIS SOFTWARE OR THE DOCUMENTATION. --- -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
Taking a snapshot look at the STATUS file at any given point in time does not show the actual problem. The problem is the delay in getting from point A (submitting a proposal) to point B (approval for backport). For a hot issue with many interested parties (who actually hold voting rights), getting a backport proposed and accepted is rather quick. In such cases I would even suggest that the backport proposal policy is simply a formality and overhead because those voting on a hot issue have already reviewed the issue even before it hit the STATUS file. So rather than just checking in a patch that has already been reviewed by the dev@ list, it is delayed simply on formality. But that is a different discussion on a minor point. The main evidence is the trend that is happening before each release. A release is proposed, an RM is selected, the RM sets a deadline and everybody emails the list with their favorite backport issue. Now the RM has to deal not only with the release but whether or not a backport has been accepted, can the tree be tagged yet, does a tag need to be moved, etc. Oh Oops a backport didn't make it and now we need to issue a release patch for a segfault(http://www.apache.org/dist/httpd/patches/apply_to_2.0.52/). Not only that but IMO, this in itself is a major contributor to destabilization. The best way to make sure that the branch is stable is to get it out in front of those that are testing and using it. Not throw a bunch of patches in right before we release just because they got three +1's. Implementing lazy consensus would make others aware of proposed backports, allow them to review the issue if interested and allow the backport to move smoothly and quickly through the process without having to beg the list for reviewers at the last minute. The opposite question is what evidence do we have that RTC isn't doing more harm than good once the branch is stable? And please don't point to the mess that happened between 2.0.35 and 2.0.4x. IMO, that mess was due to the fact that it was a first GA release and we just flat out got it wrong. It then took a few more rather quick releases to get it finally right. RTC for that period of stabilization may have been valuable, but since stabilization was achieved, it is just getting in the way of community involvement and ennovation. Brad [EMAIL PROTECTED] Wednesday, November 17, 2004 12:42:08 PM On Tue, Nov 16, 2004 at 06:10:17PM -0700, Brad Nicholes wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Looking through the STATUS file, there doesn't actually appear to be much backport stagnation at all. The majority of stale backport proposals are stale because they are pending updates from the submitter after review by others, or they have been vetoed by a reviewer. Which is all healthy. So what's the evidence that there is a slowdown of activity caused by the backport policy? There have been four 2.0 releases already this year, including 179 individual user-visible changes listed in CHANGES according to grep. Sounds pretty healthy to me. Regards, joe
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 --
Re: People still using v1.3 - finding out why
On Nov 18, 2004, at 11:43 AM, Graham Leggett wrote: 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? I think there is still a thought that php isn't mature on 2.x. (I'm using it) But some people, notably the php folks last I saw. Suggested 1.3 as the stable production server to use instead of 2.x -- Nathanael D. Noblet Gnat Solutions 204 - 131 Gorge Road E Victoria, BC V9A 1L1 T/F 250.385.4613 http://www.gnat.ca/
Re: People still using v1.3 - finding out why
On Thu, 2004-11-18 at 13:43 -0600, Graham Leggett wrote: 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 that's easy... as long as it will be the default in debian stable... people won't bother with 2.0
Re: People still using v1.3 - finding out why
Nathanael Noblet wrote: On Nov 18, 2004, at 11:43 AM, Graham Leggett wrote: 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? I think there is still a thought that php isn't mature on 2.x. (I'm using it) But some people, notably the php folks last I saw. Suggested 1.3 as the stable production server to use instead of 2.x Yes, that's a big reason in my experience. People tried using PHP with a multithreaded Apache long time ago, got burned, and are now afraid to try it again. I think it's mostly a matter of marketing now. I think it would be a good idea to go with a stable 2.2, and make a strong marketing push to get people to adopt it. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: People still using v1.3 - finding out why
Interesting question. I have just done a large scale review of our web server architecture and have recommended a move to 2.0. There were a number of factors for not moving, both specific to our installation as well as in general. In general : Remeber the old adage If it is not broke, do not fix it. The 1.3 series is still an amazing piece of software. Specifically, the arguements against moving in our case : mod_auth_oracle has not been ported to 2.0. One module I wrote would have to be redone for 2.0. This module gave us a 60% performance boost on our request latency time and has to be in any installation. I made changes to the 1.3 proxy code which I do not look forward to changing in 2.0. Due to our hardware architecture (IBM BladeCenter and Linux) scalability was not an issue. What won me over? Load balancing and fail over proposals in mod_proxy for the 2.2 series. As I am moving to a new hardware platform in December, I felt it best to bite the bullet to 2.0 now. Performance wise I noticed little difference between the two using prefork MPM. With the bladecenter there was no requirement for scalability. Thats about it. BTW if it makes a difference,this Apache installation is nothing more than a central HTTP hub for proxying to mutliple back end servers. Jeffrey Burgoyne Chief Technology Architect KCSI Keenuh Consulting Services Inc [EMAIL PROTECTED] 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
Re: People still using v1.3 - finding out why
A can think of 4 big reasons, two from a developer standpoint and two from an admin. developer: 1. Builds and compiles in a minute, rather than several. This means you can play around and develop more and compile less. 2. More streamlined design; for some filters, bb's and the dependency may be stumbling blocks. admin: 1. They are used to it. 2. Smaller footprint. At least, this is the feedback I get from people. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: People still using v1.3 - finding out why
Jim Jagielski wrote: A can think of 4 big reasons, two from a developer standpoint and two from an admin. developer: 1. Builds and compiles in a minute, rather than several. This means you can play around and develop more and compile less. 2. More streamlined design; for some filters, bb's and the dependency may be stumbling blocks. And: 3. While the 1.3 API is well documented, the documentation for 2.0 is sparse. I have always thought a good book on APR programming, possibly with a chapter or two on Apache, would do wonders for the popularity of Apache 2. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: People still using v1.3 - finding out why
On Nov 18, 2004, at 12:16 PM, Ivan Ristic wrote: Jim Jagielski wrote: A can think of 4 big reasons, two from a developer standpoint and two from an admin. developer: 1. Builds and compiles in a minute, rather than several. This means you can play around and develop more and compile less. 2. More streamlined design; for some filters, bb's and the dependency may be stumbling blocks. And: 3. While the 1.3 API is well documented, the documentation for 2.0 is sparse. I would have to agree with the above. I started trying to learn the module programming for 2.0. Most of what is out there assumes you are doing one or two things, and didn't include enough to get it all pieced together. I have to admit that I figured it all out from the pieces, but took me close to a week of comparing different modules and what they did to get my module to do integrate with apache, never mind actually work on its own. I have always thought a good book on APR programming, possibly with a chapter or two on Apache, would do wonders for the popularity of Apache 2. I agree. Though by far don't have the knowledge to do it myself. -- Nathanael D. Noblet Gnat Solutions 204 - 131 Gorge Road E Victoria, BC V9A 1L1 T/F 250.385.4613 http://www.gnat.ca/
Re: People still using v1.3 - finding out why
I think people rely on apache 1.3 stability and security. many people consider httpd-2.0 as too young and don't try to understand why it's better. Does somebody have some percentage about 1.3 use and 2.0 ? I don't think 1.3 is still here because of modules, there is too many modules and too many kind to use apache (perl, php, proxy, cache + deflate, etc...) Is php not stable with 2.0 prefork ??? But what i don't understand, is how people can say apache 1.3 is better to code with, than apache 2.0. filters are so usefull. it's a pleasure everyday to code with apache 2.0 :] This discussion remind me some before, with this eternal subject (1.3 or 2.0) I think it's a question of time, and a question of fashion... What i can say is when i go see customers, there are more who tell me they are now using 2.0 than saying still using 1.3... In case people are searching good book on httpd-2.0 programming, ryan b bloom one is perfect and really usefull to understand why it's better than 1.3. regards, Matthieu
RE: People still using v1.3 - finding out why
Please don't forget: 1. Solaris 10 is shipping with 1.3.31 2. OpenBSD's fork of 1.3 --Brett. Systems Administrator, RHCE -Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 11:43 AM 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 --
Re: People still using v1.3 - finding out why
Brett Lentz (Excell Data Corporation) wrote: Please don't forget: 1. Solaris 10 is shipping with 1.3.31 Redhat is shipping 2.0 for long time now 2. OpenBSD's fork of 1.3 openbsd and the theocracy ?? hahaha cool let them continue with 1.3 --Brett. Systems Administrator, RHCE -Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 11:43 AM 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 --
Re: People still using v1.3 - finding out why
Matthieu Estrade wrote: I think people rely on apache 1.3 stability and security. many people consider httpd-2.0 as too young and don't try to understand why it's better. Does somebody have some percentage about 1.3 use and 2.0 ? I don't think 1.3 is still here because of modules, there is too many modules and too many kind to use apache (perl, php, proxy, cache + deflate, etc...) Is php not stable with 2.0 prefork ??? It is stable. I'm sure you can get it to segfault if you tried, but the same goes with 1.3. But what i don't understand, is how people can say apache 1.3 is better to code with, than apache 2.0. filters are so usefull. it's a pleasure everyday to code with apache 2.0 :] I never thought it was a matter of coding, It's more a matter of porting. From the conversations I hear/see it is the module developer who runs 1.3 and is quite happy with it for their needs. The other factor I see in the 'auth' category of modules is that the API has changed radically in 2.1, and so some people have just skipped 2.0 for their modules. --Ian I'm waiting for the people still using v2.0 when 2.2 goes stable. regards, Matthieu
Re: People still using v1.3 - finding out why
At 01:53 PM 11/18/2004, Nathanael Noblet wrote: On Nov 18, 2004, at 11:43 AM, Graham Leggett wrote: 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. I think there is still a thought that php isn't mature on 2.x. (I'm using it) But some people, notably the php folks last I saw. Suggested 1.3 as the stable production server to use instead of 2.x Let's not lose sight of the root of this problem. In order to properly write php4apache2filter - we needed PHP's engine to allow us to push the script, IIRC... at that time Zend only offered us pull-based file handling. Instead of a real solution, this 'filter' simply assumed there was a file bucket, sucked the fd and passed that to zend. It was no filter, and it often did not work at all when the content had been parsed. Sooo... php4apache2handler was born, which solved this whole hassle by being a handler-only module. And then PHP5 was born, and now has the hooks we needed in the first place to create a PHP filter module. Fun weekend warrior project if someone wants to spend the cycles in the php5 tree. Understand that the handler works -just-fine- and with prefork there was never an issue with thread-unsafe libraries. But the project's docs continue to promulgate the FUD. Last I looked the regression rate (folks adopting 2.0 and then reverting to 1.3) is quite low, within the margin of error for most mixed-server load balanced servers: http://www.securityspace.com/s_survey/data/man.200410/srvch.html?server=Apacherevision=Apache%2F2.0.51 (substitute whichever sub-version 1.3 or 2.0 you like.) Also notice a much higher percentage adopt the latest and greatest 2.0.x release when announced than those who adopt the latest and greatest 1.3.x release. So as others noted, a large percentage of this imbalance is probably explained by bundled distros. The overall adoption is actually reasonably impressive; 4.51% are using IIS 6, roughly 9.66% (forgive rounding errors) are using a fairly stock 2.0 (not renamed), while 13.5% don't admit their version of Apache at all. Dollars to donuts, those 2.0 users are very actively aware of their installed servers and more likely to disable the version tag than those using an stock, OS distribution flavor of version 1.3. And for fun... http://www.securityspace.com/s_survey/data/man.200410/srvch.html?server=Apacherevision=Apache indicates about 3/4% of our users per month are dropping their version from our server string. It makes an interesting graph; http://www.securityspace.com/s_survey/server_graph.html?type=httpdomaindir=month=200410serv1=QXBhY2hl Bill
Re: People still using v1.3 - finding out why
From: Graham Leggett 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? Because there can only be one number one! ASF told them over and over again that it is number one. (rightly or not) The users followed ASF words Because there can only be one number one! The users believe, if it wasn't number one, ASF would have pulled it. Because there can only be one number one! ASF has not! Because there can only be one number one! Good luck, Jeff
Re: People still using v1.3 - finding out why
Personally, I have seen some hosting providers which I have talked to (and worked with) hold back because existing client's htaccess scripts sometimes experience quirks under 2.0. In one case I have been privvy to, a test implementation was done with a server that was practically a replica of a running client hosting environment (as it was created from a backup), then upgraded the underlying apache from 1.3 to 2.0 with a configuration of modules as close to the old one as possible. In that case, several client sites with dynamic applications started throwing up errors due to configuration changes (and perhaps misconfigurations) in a combination of scripts and htaccess files. In one particular case, a files block was being used to force processing of anything called in a certain directory as a PHP script in order to provide a true path-info address for a dynamic script. (instead of blah/this.php/that/that its blah/this/that/that ). I am not sure if this is still the case or not... Also, I know that in some cases, adoption of Apache 2 was delayed by integration with tools that provide some level of automated administration. In most installations, this has already been solved but it certainly hindered the initial adoption rate. -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. On Thursday 18 November 2004 12:43, Graham Leggett wrote: 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. pgpWXkrMGnDJa.pgp Description: PGP signature
Re: Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
[EMAIL PROTECTED] Tuesday, November 16, 2004 4:29:31 PM * Brad Nicholes [EMAIL PROTECTED] wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. -1 (vote not veto) Stability is much more important than backport of some features. Backporting code into the stable branch without any review will increase the risk of new bugs. What I see, is not stagnation. Instead, I do see more effort because of our backport policy. Development is done for two versions. This binds time and power. 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 Additionally, let's do 2.1 tarballs to bring the current development branch to a wider group of devs and testers. Kess
Re: Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
--On Friday, November 19, 2004 12:41 AM +0100 Astrid Keßler [EMAIL PROTECTED] wrote: Additionally, let's do 2.1 tarballs to bring the current development branch to a wider group of devs and testers. I plan to roll 2.1.1 as soon as the final import finishes: roughly a few hours from now. ;-) Go, Subversion, go! As of right now, we're roughly 50% through the import. I'll be sending an email later on tonight that has rough Subversion instructions and so forth. -- justin
Re: RFC for a Perchild-like-MPM
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? Max.
Re: People still using v1.3 - finding out why
Graham Leggett , Thursday, November 18, 2004 14:43Hi 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. I have no idea. Stupidity, laziness, fear of change. Maybe it's modules. The bandwidth throttling module might be a valid reason. Some people want to get a few more years of their money's worth that they paid for those $500+ third-party modules 5 years ago, like ASP and FrontPage or whatever. Smaller businesses (the customer) may have had very customized modules made for 1.3 and not have the cash or the incentive (low web revenues) to invest in a programmer to convert to 2.0. I used to work at an ISP as sysadmin three years ago, and everything was 1.3, though 2.0 was still reported as beta, but also reported as running the main Apache website. That's a mixed signal: either you're not confident to stop calling it beta, or you're confident to run your majorly, vitally important website with it. :p PHP is a fun language and I really enjoy using it, but I don't get the FUD crap. I've played with Apache 2.0 for over 2 years now (mostly prefork MPM) and I had only one PHP4 problem, and it was not Apache, but it was a PHP4 problem. After reading the bug database, I saw that they refused to acknonwledge it as a PHP4 problem in thepast and just blamed Apache by default when they heard mention of Apache 2, closed bugs, marked as invalid, refused to reopen or mark as duplicates, repeatedly fixed the problem (several months after it was reported), and repeatedly broke the problem again (same types of reports across multiple versions), and repeatedly announced fixes for the same exact problem. This all seems retarded, to have such animosity or unfriendliness to each other. The server is the one that the language most often runs on, and it is one of the most popular languages to ever run on the server. It would seem like a naturally symbiotic relationship with a huge incentive to cooperate. Eventually, just stop offering 1.3 for download, stop patching 1.3, remove the ability to file 1.3 bug reports, and I suppose people would upgrade, but it probably wouldn't make any friends. ;-) Leif
