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."

Comments

Great Job ASF

[webperf]

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!

Re:Bid Update?

[Coneasfast]

I don't get the feeling that this is a very significant update!

any project in it's mature stages wont change much, at least not noticeable by most users.
if bash creates a new release, you aint gonna notice the difference.
if linux creates a new release, you aint gonna notice either (unless it's a major release, but in comparison, this apache release is not)

Do you really need to change?

[CyricZ]

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.

Thank god for LFS.

[Anonymous Coward]

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).

Re:Thank god for LFS.

[m50d]

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.

The point is not that you don't need to do it, it's that if you're using http to do it you're an idiot. Claiming that http servers need to support over 2gb is like claiming that DNS servers need to. And show me a real reason to go for 64-bit on the desktop.

HTTP works where FTP has problems when dealing with complex networks (firewalls/NAT etc etc).

No it doesn't unless you try and run a server from behind a firewall. Just use passive mode and it will just work just as well as http.

Re:Thank god for LFS.

[Slashcrap]

No it doesn't unless you try and run a server from behind a firewall.

And who the hell would want to run a server from behind a firewall? What a ridiculous idea.

Just use passive mode and it will just work just as well as http.

I see you've never configured a firewall then.

Claiming that http servers need to support over 2gb is like claiming that DNS servers need to. And show me a real reason to go for 64-bit on the desktop.

He gave some perfectly valid reasons for wanting LFS - WebDAV for one. You ignored them, probably because you didn't understand them. And then you called him an idiot. At least your sense of irony is well developed.

Re:Thank god for LFS.

[Renegrade]

FTP is a horrible protocol - two TCP streams to do the work of one? Secondary connection data stored in the first connection's stream? No real standard to getting stat() info on files? No resumes/byte ranges in the base standard? On the fly ascii translation??

While HTTP has it's own warts, it does support things like byte ranges, proxying, single TCP stream transfers, etc.

I'd personally love to see a new FTP2 protocol that ditches all the old mainframe stuff, kills the ASCII transfers, and allows proper stat()ing of files (could have different modes like STAT BASIC (size, mtime, r/w status), STAT UNIX (size, all *times, 0777 perms, owners, etc), STAT WINNT (windows ACL data) STAT UNIXACL, etc), allow byte-range download specifications, all over a single stream, in a single protocol in a single RFC.

Re:Thank god for LFS.

[Nevyn]

DNS can't support LFS tyep sizes, you would actually need to change the protocol. HTTP on the other hand has worked fine with LFS for a _long_ time, just not if you are using apache-httpd.

And as another webserver author, I can give you a couple of reasons for using HTTP over FTP:

• Caching proxies, esp. helpful at large organisations where many people will be requesting the same data
• proxies ... often it's the _only_ way out of the network (well you can somtimes do FTP over HTTP).
• at a protocol level, HTTP is at least as efficient/suitable as FTP for transfering files of any size ... indeed you could easily do the HTTP by hand, this is _much_ harder with FTP
• You still get the other benifits of HTTP, like content negotiation (like getting avi/mpeg or zip/gz/bzip2 depending on which you'd prefer) and caching (Ie. ETag)
• If anything is more "suitable" for large transfers it'd probably be bittorrent, not FTP ... but even then bittorrent has one plus but fails most of the above

Re:GUI?

[code65536]

I've used the IIS GUI once because I was curious. *shudder* GUIs are useful only when well-designed.

1/ There are Apache GUIs. Google them up. Some are free, some are not.

2/ Opening the config file in a GUI text editor and navigating around with a mouse should be fairly easy, especially with the copious amount of documenation in the config.

3/ It's very difficult to express the rich level of complexity of Apache configurations in a GUI. Just imagine how on Earth a GUI can be made to handle nested VirtualHosts, Directorys, and Files. Throw in some regexp, and suddenly, you are faced with a situation where it becomes a heck of a lot easier to just edit the config file. To say that a GUI is always easier than text is incorrect; it depends on the situation, and Apache configs are one of those situations where this is the case (kinda like how when dealing with non-photographic web graphics, you need to use PNG or GIF and avoid JPG like the plague and how when dealing with photographic web graphics, you have to use JPG... each rules over their own niche of strength).

4/ If a GUI is made, it is highly likely that it won't be as powerful as just using a text editor; it's not as expressive (see above). But there's really not much to do with the basic configuration, either. For the most part, the default configuration works just fine, and if someone needs to edit the settings, it's mostly for the complicated stuff that would be a bloody mess to do in a GUI.

5/ Compactness and portability.

Re:How does 2.2 stack up to 1.3?

[cortana]

IIRC, 2.0 has been stable/recommended over the 1.x versions since 2001.

Re:Jeez

[Anonymous Coward]

A lot of low-cost, high bandwidth sites have long ago switched to lighthttpd, disgusted by the bloat that bogs down the new Apaches.

The process is comparable to the demise of the Mozilla-browsers: long time a favorite of power-users, their concentration on mass-market AOL-lusers has caused to product to get bloated with half-assedly implemented, useless features and made power-users switch to Opera.