15

The Apache HTTP server is a fairly large project—much larger than, say, lighthttp or nginx or certainly the "simple HTTP servers" you see floating around in C/C++ tutorials.

What is the extra code for? Does it add security/stability (and if so, how?) or is it just for doing things like parsing Apache conf files/.htaccess type things (and, I guess, VirtualHosts etc).

I ask not to critique Apache, but because I'm interested in writing a web server of sorts and I'd like to know things that, while perhaps not obvious, are important to remember for a secure, stable and fast web server.

Aaron Yodaiken
  • 253
  • 2
  • 6
  • 1
    It helps to weed out all those who don't pack the gear to handle it. – Joel Etherton Jun 03 '11 at 01:02
  • 7
    Its not a real answer - but I heard the name comes from the fact that it had a lot of contributors even early in development. Lots of patches were contributed, making it A Patchy server. True story. – Jeremy Jun 03 '11 at 01:04
  • +1 @Joel Etherton: Good story, especially that it's true. But never let the truth get in the way of a good story :) – therobyouknow Jun 03 '11 at 07:51
  • +1 @aharon for an example of questioning the status quo. But "writing a webserver"? Aren't we re-inventing the wheel here when there are many offerings as well as Apache? – therobyouknow Jun 03 '11 at 07:52

4 Answers4

21

It's a lot more complex because:

  • it's older,
  • it's got a larger of feature-set (Feature Set Comparison),
  • it's modular,
  • it's got a wider platform support (OS Support Comparison),
  • it's got multiple modes of operation (multi-process, multi-thread, etc...).

But also:

  • It's more actively developed (Status Comparison. As of today 2011-05-28, Apache httpd has the most recent update, though its inherent release process should be hampered by its extended complexity as opposed to its competitors.)

That being said, R.'s answer contains valid points about its architecture and why some other web-servers benefit of relative fame as well. It depends on what you want.

You may also want to look at https://stackoverflow.com/questions/475386/apache-vs-nginx-vs-lighttpd-which-is-simpler-to-configure-and-administer for some more material. Though not directly answering your question, the whole thread points out a lot of differences.

If interested in writing a web server from scratch, I'd say studying Apache httpd is a good thing, especially if you can look back at how it evolved over time. It also shows you what you need to avoid (both on points it addressed well, and places where it's outperformed by others). However, the code might be a bit complex to start with and you might prefer to look at smaller, more light-weight servers for that. But do study its overall architecture and compare it with others.

Community
  • 1
haylem
  • 28,856
  • 10
  • 103
  • 119
  • 1
    +1: Just reading through the changelog history can be incredibly instructive in learning how the web server itself evolved and what challenges the team went through over the years. – Joel Etherton Jun 03 '11 at 01:03
  • 1
    +1 @haylem " some other web-servers benefit of relative fame" - it's reassuring to read about alternatives to Apache that are said to be Apache-compatible i.e. will do just about the same job. – therobyouknow Jun 03 '11 at 07:54
  • FYI that SO question you linked comparing Apache, Nginx and Lighttpd no longer exists due to "This question was removed from Stack Overflow for reasons of moderation". I have no idea what that means! – Peter M Apr 07 '22 at 15:10
3

In my personal opinion it is all because of all features it has. You can do things with Apache you could not do right now with neither nginx or lighthttpd. Apache is actually a platform that happens to ship with HTTP support. You can have just about any protocol implemented like FTP or SMTP (see mod_echo for example). It has support for filters which allows you to eg.: serve PHP code off database instead of files (since mod_php is a filter module and not content producer). This might seem like not very usefull idea, but in general you can use filters to alter any content going in or out without the need to tweak original content producer. It has tweaks for HTTP clients that are not around anymore, but back then, Apache was the only way to serve them in a consistent and bug free manner. Much of it isn't used nowdays. Some of my Apache instances works only with 3-5 of the standard modules.

The extra code is also used for security, because mod_log_forensics together with CoreDumpDirectory provide a real tool when you feel someone is exploiting a security vunerability. Haven't heard about anything like that in case of other web servers. As for stability, it comes from well architectured core, not some extra code. There are guys on Apache dev mailing list, that are called "core stabilizers". They are very picky about any change in the core and tend to push them to modules, which actually makes Apache quite stable. If it fails, most of the time it's a failure of module and not the bug in server core.

Jacek Prucia
  • 2,264
  • 1
  • 17
  • 15
3

I have used Apache for over twelve years as both an administrator and developer for large Perl, Python, and Ruby web applications. Apache is a rock-solid web server which has a clean/modular design and a strong UNIX bent. One of it's most powerful features is its sheer modularity and good documentation. It is a very manageable web server. It's mature and proven as can be clearly seen by 15 years of dominant market share.

While the user documentation is very good, there is unfortunately precious little documentation for developers/module writers, and I think this tends to hurt it a little in that it doesn't attract as many developers as it could. But that in no way means that it's poorly designed -- just poorly documented in this respect. There is a book by Nick Kew which seems to be the definitive resource for module writers. But it would be nice if the project itself had some better documentation on all aspects of writing modules.

As for it being over-engineered -- hogwash. It has an excellent design. Yes, there are some warts here and there, but that's true for all software. It's use of memory pools is fantastic, it's ability to plug in different back-ends speaks to how clean and modular it is, it has a great C-API, and the APR makes many things much easier not only for the Apache project for for developers in other projects. If you care anything at all about portability, you will appreciate the APR. It may not be perfect, but it's still solid, well-designed, and very convenient.

From the standpoint of sheer features, flexibility, administration, platform support, scalability, documentation, and maturity, Apache is a fantastic web server.

Mike Owens
  • 339
  • 1
  • 7
-1

It's over-designed/over-engineered. Worst of all, it uses APR (Apache Portable Runtime), a bloat layer that ends up spending many levels of function calls and dynamic memory allocation and freeing to accomplish the equivalent of a single printf call. This all leads to it being:

  • very slow
  • very resource-hungry
  • impossible to audit for security
  • difficult to understand and modify
R.. GitHub STOP HELPING ICE
  • 656
  • 5
  • 10
  • 5
    You mostly point out the pitfalls of its complexity and (arguable, depends on what parts) bad design; However valid these statements may be, they're not *causes* for its complexity. – haylem May 28 '11 at 02:38
  • 1
    -1 for the APR bloat. I was working with APR in the pre 1.0 era and back then it wasn't introducing any more bloat than already was in 1.3 codebase. Also dynamic memory allocation in APR is more or less an exact copy of 1.3 memory code. And even if you're right... how does a bloat of any kind make something impossible to be audited? – Jacek Prucia Jun 03 '11 at 06:34
  • agree with @haylem (+1) and also: those four points in @R..'s answer: how do you know? What are you comparing against. You may be right but your points are going to be relative, i.e. "very slow" - but compared to what? Another server like those mentioned here? If so please cite them. – therobyouknow Jun 03 '11 at 07:50
  • 1
    I believe the thttpd website has some good figures for static content. What's more surprising is that, from personal experience running a web-based student homework system, Apache was also **a lot** slower with `mod_perl` than thttpd was just running a new perl instance for each client. This was a long time ago and I never did rigorous testing to track down all the causes; the department just bought a new server... – R.. GitHub STOP HELPING ICE Jun 03 '11 at 12:23
  • @R.: yet again, why would you run it with mod_perl :) – haylem Jun 03 '11 at 13:07
  • `mod_perl` is supposed to be faster by avoiding the overhead of re-running the interpreter from scratch for every script that's run. – R.. GitHub STOP HELPING ICE Jun 03 '11 at 22:51
  • @R: Yes, but the intent of the (possibly bad) pun was more to point out that I wouldn't care to write anything using mod_perl. Performance would be one reason for that, but definitely not the only one... – haylem Aug 08 '11 at 23:59
  • I know that this is an old thread, but I feel compelled to comment, writing new code which targets `mod_perl` specifically is dis-recommended. Instead, one should use one of the _many_ excellent psgi-based frameworks which allow one's perl web app to be run (without modification!) using any of mod_perl, mod_fastcgi, mod_psgi, mod_cgi, nginx, lighttpd, starman... – BenGoldberg Jul 17 '17 at 01:01