Slashdot Mirror
Apache 2.2.0 Released
ikewillis writes "According to an announcement on apache.org, Apache 2.2.0 has been released. From the announcement: 'This version of Apache is a major release and the start of a new stable branch. New features include Smart Filtering, Improved Caching, AJP Proxy, Proxy Load Balancing, Graceful Shutdown support, Large File Support, the Event MPM, and refactored Authentication/Authorization.' View the ChangeLog or check out the new feature list."
Now I'm .9 versions behind.
Not bad, but when do we get the ability to make confguration changes with restarting Apache?
The roots of education are bitter, but the fruit is sweet.
--Aristotle
I'm waiting for Microsoft to rename IIS "Cowboy 1.0" :)
I read the feature list and changelog earlier today but without taking the time to set up a test server and experiment with it I really have no idea how it compares to 1.3. For the most part we have stuck with 1.3.x for it's stability, performance on our older hardware (from 256MB dual 75MHz SPARCstation 20 to 1 GB 440 MHz Netras), and rock solid compatibility with mod_perl and Perl 5.6.
I'll be willing to try upgrading in the near future in hopes of experimenting with and making use of the some of the newer featues, but I would like to hear some first-hand information from those who have recently made the leap to 2.2, if at all possible.
OK, I'll admit, the added feature list seems impressive, and I'm drooling a bit... but for some reason (I'm honestly not really sure why) I don't get the feeling that this is a very significant update! I'll find out tomorrow when I test it myself :)
LINUX ONLINE POKER: Linux Poker
So... it runs on Linux... But what doesn't it do ?
You can also do this: apachectl -k restart
A round of thanks to all the hard work done by the HTTPD team.
you guys ROCK
and special thanks to paul who pushed this through!
That's interesting how they jumped from the 2.1.x beta versions to 2.2.0. They didn't do this when they went from the 2.0.x beta to the 2.0.x stable (hence the large .55 attached to 2.0.x right now). It's kinda like what Perl does with having devel and stable versions have odd and even numbers, respectively.
;)), I have this feeling that we might see the same 1.3->2.0 inertia.
Anyway, I guess the big question is, how many people will actually adopt 2.2.0. I still remember when 2.0 came out to mostly a yawn as most people kept using 1.3.x. Even today, most of the servers that I come across or administer are still using 1.3.x because unless you were running Windows, 2.x didn't really offer spectacular improvements over 1.3.x, and looking at the changes for 2.(1|2).x (anyone who's going to transfer a >2GB file over HTTP is crazy
When are they adding the continuation-stored-in-the-server feature? Having to do a CPS transform essentially by hand to all CGI scripts is ridiculous. Oh yeah...Perl/PHP/etc. don't support that. Why not?
I've been struggling with setting up a mirrors server for our computing club here. I'd like to mirror all of Debian, for example, but I'm finding that storing (and, worse, updating) 80 gigs only to serve a tiny fraction of the files to our users is a dismal trade-off. I had been experimenting with ProxyPass, but since it didn't cache the results locally, it wasn't really providing a speed benefit.
mod_disk_cache plus mod_proxy's ProxyPass seems like just the ticket - I could give it a few servers to proxy for, give it a few hundred gigs of cache, and it would then automatically intelligently cache for those servers. This would be a great, easy plug-in solution.
Has anyone used mod_proxy and mod_cache in this fashion? It'd be great to hear about others' experiences or configuration examples.
|/usr/games/fortune
What are the newer features that you're planning on using?
Indeed, it sounds like you have what may be the perfect situation. Even if your servers are somewhat older, and not the most powerful, they are still very solid Sun systems. They will basically last forever. You suggest that mod_perl is working very well for you at the moment, too.
Perhaps an upgrade would be the worst thing you could do. Sticking with older, proven systems is many times a very wise idea.
Cyric Zndovzny at your service.
Apache 2.x? No thanks!
Apache 1.3? Still has issues!
I think I'm going to stick with something I can really trust!
Maybe I'll try CERN httpd 2.14, I'm not sure if 3.0 has enough of a track record.
I am really glad they added Foxy Load Balancing. Now asianpornstarlets.com will send me data at a nice, steady pace instead of in spurts and dribbles.
Storing state in the server and retrieving it via cookies, etc., is not CPS, it's just saving and retrieving state. And who still uses CGI anyway?
And who says continuations are a valid way to write web apps? I prefer to use request/response because that's the model of the underlying architecture. I also want my URLs to represent named entry points, not continuations within some arbitrary program.
And how the heck would Apache know how to save a continuation in any arbitrary programming language? Or is Apache supposed to turn into a set of libraries, one for Smalltalk, one for Ruby, one for Lisp.. ?
Explain what you mean, son....
For those of you saying you don't need to transfer >2GB it reminds me of comments like, "640k is enough for anybody", "64-bit isn't needed on the desktop", "no advantage to dual core" etc etc.
This will finally mean I can wget DVD ISO images! Work with large files over WebDAV and it will also mean my logs can grow over 2GB which is cool.
HTTP works where FTP has problems when dealing with complex networks (firewalls/NAT etc etc).
Sweet! Now I can store the 9.1GB DVD ISO's for people to download off my 33.6k Modem connected webserver!!
;-)
But seriously, the timing of this feature being added couldn't be better, 5 years ago there would've been no point, but with the current rate of speed increases in home Internet, it will become somewhat more useful!
----- Concentrate on promoting more than demoting.
But I want /debian/ to be a Debian cache, and /ubuntu/ to be an Ubuntu cache, and it'd be nice to have e.g. a Cygwin cache in /cygwin/ . Many "mirrors" sharing one disk cache space allocation on one easily-administered server.
Can Squid handle that kind of flexibility? That's what drew me to Apache's ProxyPass.
|/usr/games/fortune
Ive never really seen a reason to update apache so regulary. its been so stable for me no matter how i used it. But large file support? Nice. Pitty i still have 56k...... :(
Tried a few years ago and was kinda put off by the lack of a GUI,
how is the situation now?
MikMik Baby Organics Mikkaworks
FWIW there's a debian-specific solution in the form of apt-proxy, a program that runs on your server, then the clients point their /etc/apt/sources.list at you, etc. etc. I haven't used it, but I know it exists, so your mileage may/will vary. (At my last job I was responsible for setting up a large web cluster; one machine acted as sort of the "mothership" providing all sorts of network services to the web hosts and so on... I was just looking into apt-proxy when I ended up getting a better job elsewhere. ;))
http://apt-proxy.sourceforge.net/
But its apachectl graceful. The -k isn't needed. Reloads the configs without dropping active connections, very nice for production systems.
Quack, quack.
When apache first introduced mpm I was looking forward to the ability to have each virtual domain run under a seperate user. Right now it will spawn a seperate process for each user specified. So if you are hosting 1000 domains on one machine and specify unique users for each domain, you have 1000 idle listener processes when you start up the server.
I'm thinking the way it should be is only spawn processes for the specified user when an incomming request needs to be served, keep the process around to serve new requests if there are more to serve, and kill it off if there is no requests in X period of time. This would surely make hosting things like cgi much more secure.
The goal of computer science is to build something that will last at least until we've finished building it.
but how to compile apache 2.2.0 under win32 with icc? thanks
Run Apache 2.x on the web facing side and use mod_proxy / mod-rewrite to serve your 1.3 pages to prevent any re-writing etc.
You can then migrate bits of uri at a time.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
i just want to know when i'll be able to restart each vhost independently, like in IIS. or atleast have it rehash the config with out shutting the server down ( or is that already possible )?
In the mean time (ie, since the 2.0 release) we've changed the versioning model to the "odds are dev, evens are stable" model. So as soon as 2.2 released, development moved to the 2.3 branch, which will release as 2.4. So, yes, like Perl and Linux and many other things.
As for transferring >2GB files, this comes up many times every day on #apache, and fairly frequently on the mailing lists, so people do actually want to do this.
Folks that are still using 1.3 are missing out on enormous strides forward. The "it still works fine, why should I upgrade" crowd are completely welcome to remain where they are, and we're not going to compel to move, but they are going to miss out on all sorts of cool things, in the name of "it's good enough already." Their loss, not ours.
Apache guy, Open Source enthusiast, runner
Knowing which DSOs will load will be incredibly helpful, especially in distros that include packages for modules.
I've been waiting for LFS support in Apache for so long! OSX exports all of it's NFS shares as 64 bit, which has the adverse issue of any readdir() call returning empty. mod_autoindex always returned a completely empty directory listing.
...which no one will use.
Just like the last stable branch.
Thankyew, thankyew, I'll be here all week. Try the veal!
With spending like this, exactly what are "conservatives" conserving?
Folks that are still using 1.3 are missing out on enormous strides forward. The "it still works fine, why should I upgrade" crowd are completely welcome to remain where they are, and we're not going to compel to move, but they are going to miss out on all sorts of cool things, in the name of "it's good enough already." Their loss, not ours.
I haven't upgraded because most new security problems reported in Apache are for the 2.0.x branch, not the 1.3.x branch.
You say I'm missing out on enormous strides forward, but aren't I also missing out on numerous security problems? I'm not being argumentative, I really am interested in hearing the Apache developer's side of things. (E.g., perhaps the issues have been overstated, perhaps they exist in 1.3 also but aren't being discovered, etc.)
The earth-shattering feature of Apache 2.2 is RFC 2817 SSL Upgrade. Basically, any HTTP connection can upgrade itself to HTTPS without reestablishing.
This means you can do SSL on virtual hosts without a dedicated IP address. This will greatly increase the penetration of SSL (plus free certs like CaCert) and encryption in general. The $5/mo webhosters will be able to offer SSL to clients. Ubiquitous encryption considered good.
This is, of course, a Catch-22 - there are no browsers with the capability yet (let's get Mozilla going...) but this is the necessary first step. Come back in a couple years and see how things are going.
Oh, and I'm happy about the Cookie proxying patches which I reported against 2.0 but were applied to 2.1. This is the only Apache feature I've ever had a hand in designing so I'm happy to see it available. Basically, anything you do with cookies (paths, domains) should be properly proxied now. I've been waiting for this for a long time. Yay!
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Surely I'm not the first to notice it's not out for Windows yet?
... bit of a cheek calling it a "release" when there are no binaries. How is it different from what we could pull from the repository any other day of the week?
After the 2.0 release the ASF decided to change the way they do versioning of their products to a "odd" unstable development tree and "even" stable release tree. This was done to not cause all the confusion over the 2.0.x numbering (where the stable and unstable were both called 2.0.x)
And the authorization/authentication system rewrite is a nice BIG improvment over the old authentication stack. The new one allows you to explicitly specify which "backends" to use to authenticate and in which order.. Plus all backends can be used to plain and digest.
And for module developers (which I am) the 2.0/2.2 model is so much better than the old 1.3 module system and allows a lot more flexability and control.
The memory pools concept of APR is completely at odds with C++ programming and is very awkward to use. Nevermind the fact that the API memory pools seriously _slow_ down multithreaded programs rather than speeding them up since they prevent the efficient use of the Hoard memory allocator.
The "it still works fine, why should I upgrade" crowd ..
but they are going to miss out on all sorts of cool things, in the name of "it's good enough already." Their loss, not ours.
Why not say: it 1.3 does everything you want it to do then you do not need to upgrade. If you see something you do need (therefore 'it works fine' may not be true for a given value of fine) then upgrade.
Except that is all implicit in the minds of every other reader.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
> ... And who still uses CGI anyway? ...
... I also want my URLs to represent named entry points, ...
Without the Common Gateway Interface (CGI), HTML-based forms that submit data via HTTP or HTTPS simply wouldn't work (assuming some other alternative hadn't been developed).
So, to answer your question: CGI is used by everyone who has a form on the web page (plus many other uses as well, such as direct links to URIs that expect GET method input), which makes CGI extremely common-place. It is also not uncommon to see it used in concert with Apache's SSI (Server Side Includes) by way of the "exec cgi" or "include virtual" commands embedded within HTML file comments.
As a point of interest to other readers, this form I'm using right now to type these comments on one of SlashDot's web sites results in my data being submitted via CGI using the POST method when I activate the "Preview" or "Submit" button.
>
> not continuations within some arbitrary program.
That makes sense because it simplifies bookmarks for end users, and links for other web site developers. I agree with this approach 100% as I have the same desire to have cleaner looking URLs and URIs.
--
Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com/
> ... I would personally settle for a configuration file format ...
... a Novell NetWare network.
> which isn't confusing, poorly organized, and often times not
> parsed correctly (ie, apache doesn't do what the docs imply).
When I encounter comments such as that, I immediately wonder if the author has difficulty using computers in general.
The Apache file format is the most logical, flexible, scalable, and easiest to maintain, and includes some of the best documentation I've ever seen compared to commercial and other free software. I particularly like the way Virtual Hosts are handled, and how the Location section directives make it so easy to do so much with very little effort. I've had zero problems with HTTPD.CONF file modifications, and particularly appreciate Apache's refusal to load when an error is encountered (configuration files should always be perfect).
In my own projects, I'm adopting this format, and am currently starting work on a Java library to read configuration files that are formatted in the same manner as Apache's HTTPD.CONF so that I can maximize flexibility while maintaining simplicity in future server and other applications that are on my drawing board.
When evaluating new products, if a product has a proper implementation of the Apache-style configuration file format it automatically gets a higher rating in my scoring system.
Some folks think XML is the way to go. It certainly has its uses, but I'm not a big fan of overhead, and when it comes to network management it's obvious that Apache's format is much easier to maintain in this regard. I'm very disappointed that Apache James uses XML for its configuration files, and this is one of the many reasons I don't bother with James at all.
There are other products that use the same configuration file format as Apache's, such as ProFTPD ( http://www.proftpd.org/ ), and this is a trend that I hope continues with other well-managed projects (both free and commercial).
--
Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com/
This message originated from within a secure, reliable,
high-performance network
Anyone know if there will be future security patches for the now older 2.0.x version? I.e. should I figure on upgrading sooner rather than later to minimize the disruption the next critical bug fix comes out?