Slashdot Mirror

thttpd is a simple, small, portable, fast, and secure HTTP server.

Simple:
It handles only the minimum necessary to implement HTTP/1.1. Well, maybe a little more than the minimum.

Small:
See the comparison chart. It also has a very small run-time size, since it does not fork and is very careful about memory allocation.

Portable:
It compiles cleanly on most any Unix-like OS, specifically including FreeBSD, SunOS 4, Solaris 2, BSD/OS, Linux, OSF.

Fast:
In typical use it's about as fast as the best full-featured servers (Apache, NCSA, Netscape). Under extreme load it's much faster.

Secure:
It goes to great lengths to protect the web server machine against attacks and breakins from other sites.

It also has one extremely useful feature (URL-traffic-based throttling) that no other server currently has. Plus, it supports IPv6 out of the box, no patching required.

Hello Coward.

Yes, HTTP is a pretty complex protocol. However, you can write extremely simple read-only servers, such as thttpd or publicfile.

Almost all projects that publish anoncvs also publish web pages, and putting additional files on the web site is much less risky than running a whole new server.

Distribution makes untrusted input problems worse since components of your 'server' can no longer even trust each other.

The version control system doesn't trust the web server, or receive any input from the network.

Thankyou for trolling!

Yeah, I haven't found a good SPF implementation either. Perl, ugh, I sure don't want that in my mail delivery path. I might just write my own C SPF milter, I've been playing with milters lately and they're a lot of fun. Here's my latest, it does IP-based blacklisting very efficiently.

...i.e., this.

Hopefully they've set up throttling...

...i.e., this.

Hopefully they've set up throttling...

I'm one of many who has dropped Apache in favor of thttpd.

So the next time you're setting up a webserver and Apache is being a pain in the ass - kill it and switch to thttpd. You'll thank me.

My solution for a room of three people (including me): An old PC with a soundcard, a pair of el-cheapo passive speakers, an ISA-Bus FM radio card, and a selfmade floppy-sized Linux. It runs a tiny webserver (mini_httpd), dhcpcd, and three CGIs, one to select the radio station, one to control the soundcard's mixer, and one to control the CDROM drive (Audio CD only). After booting, the sound volume is set to background level, and a local FM station playing acceptable music is tuned in. Now we can control everything via web browser, and (because I had too much time) a CHM (Windows HTML Help) file. Station names are stored in a text file on the DOS-formatted floppy, so we could easily update the station list when needed.

Imagine some better speakers and you have music for the entire classroom. OK, my solution has no MP3 player, but it would require just one more CGI and some kind of mass storage device full of MP3s (CD-R/W, DVD-/+RW, USB Flash, Harddisk, CF, whatever). You may want to look for some self-made Linux-based MP3 players, they usually have a web interface for play lists (and perhaps volume controls).

Tux2000

For anyone who isn't that fond of Apache (that would be me!), you should be aware that you have other options.

For example, very excellent thttpd.

If you've ever been frustrated with Apache's complexity, bloated size and poor performance - try thttpd!

How many of those operating systems use Apache?

You mean including Windows, all of them can, but there are fare more webservers available for Unix like systems than there are for Windows. Thttpd, wn, Thy, Roxen, Fnord, Dhttpd, Caudium, Bozotic, Boa, and AOLserver are all available in Debian in addition to Apache. Most of these are IPv6, ssl/tls, and cgi capable. They all have their strengths, and they all are being actively maintained. Most of these will operate as a drop-in replacement for Apache for most sites.

You are correct that most of the web servers on the net are Apache installations of one type or another. Most sites do not need or use all of the features that Apache offers, but install Apache anyway. Sound familiar? They are still thinking in traditional market terms, instead of looking at what is available to them. They treating Unix as if it were Windows, but if an cross-platform Apache-specific worm were to affect them adversely, there will be alternatives available to them that they would not have on Windows.

The point is that Unix like operating systems offer greater variety of more services in more implementations than Windows does or ever will. There is more room for fault tolerance, more methods available, and more capability to find new solutions to new and old problems (including security) in Free Software than any company or group of companies is capable of providing.

5. It doesn't use a famous trademark (at least they didn't name it Nike)

Just picking nits here, but I would remind everyone that Nike didn't come up with that name on their own, Athena's been using it for just a little while longer.

I doubt that even if they *HAD* called it "Nike", Nike would have been able to do anything about it unless the Mozilla Nike project was also about manufacturing and selling tennis shoes. After all, Nike, Inc. aren't the only ones to use the name of the popular Greek goddess for their company or organizations -- the US government even used it for a ground-to air missle program.

This whole discussion is giving me a hankerin' to go try and DL some old FireFox roms for my atari emulator.

You forgot the mention the mighty thttpd!

If you need to get really small, and don't need much by way of features, micro_httpd, but that's probably overkill (underkill?)

If you need to get really small, and don't need much by way of features, micro_httpd, but that's probably overkill (underkill?)

If you need to get really small, and don't need much by way of features, micro_httpd, but that's probably overkill (underkill?)

• thttpd *n*x open-source, 50KB executable, I'm running this on a floppy/486 firewall
• Simple Server Windows freeware, <1MB executable
• Serving ditto
• TinyWeb Windows, Delphi source, BSD-ish licence, 53KB executable
• Simple HTTP Server Windows/Linux shareware, <100KB executable

The 'httpd.conf' file is a long and critical one.

For this reason, and for several more, whenever I don't need any of the multitude of Apache features, I install one of "mini servers" - for quite a while I was going on Boa, later switched to Mathopd, but I consider THTTPD or any of several other "tiny" webservers. Small, smart, fast and easy to configure. WAY easier than Apache.
(yeah, you may think you configured Apache right because it works... but what if you just opened several security holes you didn't understand? It's much better to have a tiny config file you can use for 8 things out of which you need 6, and understand all thoroughly, than one with 400 things out of which you need 12 and understand thoroughly less than 50.)

...so many even tiny sites - home PCs, private tiny hosts and such, run Apache.
It's big. It's slow. (okay, it can stand a big load without much slowdown, but overall latency is high) It's a system hog. These computers are often older Pentiums, sometimes 486s, sometimes used as clients/terminals, sometimes serving several other tasks.

Why people so rarely use tiny HTTP servers like Boa, Mathopd, thttpd... especially, that those tiny thingies are extremely fast under light load, light on system resources, have most of features every "amateur webmaster" wants, and because of small code base, usually completely bug-free.

Field for "Evangelism"?

Try the Acme mapper which provides a low weight front end to the Microsoft TerraServer. It's really nice to get aerial photography of an area that fills at 1600x1200 screen. It's also useful over dialup as it avoids the heavy weight of ads common on other mapping sites.

You might also want to look at thttpd for serving your graphics. Unless you have an amazingly fat pipe (or slow CPU) this should be good enough to deliver all your network connection can handle.

To a purely static server, like thttpd. Then you can focus the dynamic servers on serving purely dynamic stuff, and optimize accordingly. Also, MySQL 4's query cache is a great thing, so if you're not using it yet, look into it.

"micro_httpd is a very small Unix-based HTTP server. It runs from inetd, which means its performance is poor. But for low-traffic sites, it's quite adequate."

Sometimes reading the manual is useful...

If your system is robust enough to actually display this text and not lock up, well, congratulations!

Yay for me! BTW: Go to the top of the dir ( http://www.acme.com/jef/killer/) first 'cuz the web master very wisely put "referrer protection" on the page and you can't get to it from an outside link. My version of Mozilla handles this page fine but my version of Konqueror got a little bogged down trying to render the page. I'll bet there are browsers out there that would indeed totally choke on that teeny tiny little gif... only 33k file size and I watched it consume nearly 200MB of memory to get rendered in Mozilla. Now that's entertainment!

BTW: for those of you whose browsers can't render the image... it's a black gif background image of 7000 by 7000 pixels.

This is just a very large GIF. It's a single color, but is thousands of pixels on a side. In GIF form it compresses down to only a few kilobytes, but when your computer tries to uncompress it for display it balloons out to a whole bunch of megabytes. At the very least your system will take a long time to do the uncompression and display, during which time it will be unresponsive. Most likely your browser will run out of memory and fail to display the GIF, possibly exitting. Some people report that their computer actually reboots.

If your system is robust enough to actually display this text and not lock up, well, congratulations!

By the way, I had to write a custom program to produce a GIF this big. The standard GIF writers crapped out on sizes that could still be displayed.

My PC handles this page without a problem. It might cause problems on older PCs. Of course, you could always put more than one such GIF image on a page.

When I was in college, I hit the MSU Salvage Yard (Located here) every couple of weeks.

I've seen everything from (lots of ) lab equipment, to a PDP-11, to the old clock from the campus belltower, to whole pallets of workstations for sale there over the years.

I still try to swing by there a couple of times a year, to see if there is anything really really cool lying around.

While it may be a long trip for many people, check with large schools near you to see if they have public sales of stuff that was lying around.

You should look into thttpd. It has some very robust throttling features and a concurrency model that makes sense. It's also usually faster than apache for just downloading files (and if you're just serving up files and not dynamic content, there's not much point to using apache).

Here is the section that explains how throttling works. From what I understand you would like to do, you would set up some directory trees:

site.com/anonymous/
site.com/registered/
site.com/paid/
etc.

Each of those directories contains symlinks to the files you're serving, and a .htaccess password file (the symlinks point into the /anonymous section (or whatever is the "lowest" class) so it won't help people if they start guessing URLs and it's still within the site's main directory so you can still use thttpd's chroot feature). You then use thttpd's throttling features to limit the bandwidth in each directory hierarchy however you like (using simple URL patterns). Users will like it since when they click on a link, it just pops up a standard password dialog box and the browser keeps track of the password if they download multiple files in a hierarchy.

This will literally take you only minutes to set up: thttpd has no dependencies or important compile-time options to worry about, it compiles in seconds and it has one central configuration file that's small, simple and well-documented. In addition, thttpd has never had any major security holes, it has an excellent concurrency model that keeps serving up files without bogging down the machine even under immense loads, and the throttling features are well thought-out

If you only want to send out files, you might want to stick with the warm fuzzy feeling by knowing you've only got apache exposed to the outside world.

Even better, use a chrooted thttpd without all of the fuss of apache plus a jail environment. It serves quite well for one-way distribution of publicly-available files.

Eat Food - Well, you can't download a hot dog, but you can find things to make eating more pleasant or order food online.

Breathe Air - You could suck down the power supply exhaust, but that doesn't really count. You can however check to see if you can breathe when you go outside.

Sex - Technology has not advanced that far yet, but I've had good luck meeting new people online, then meeting up with them in person.

Ride a bicycle - Buy parts, plan routes, get maps, etc..

Walk through the woods - here you go - it's a QTVR I made a couple of years ago of a walk along a creek to the river it joins up with. All kidding aside, this one probably can have the most computer involvement. After all, you want to get topographic maps somewhere, and maybe check out an overhead view of the area you plan on walking through, not to mention sharing details of where you went with friends.

Jef Poskanzer's Experimental Command Line Interface allows interactive usage of several programs; as a demonstration, it lets you play Adventure!

If it does require a server side piece, it's not a web browser, per se; but as a general question, is it worthwhile to look into "compressed" web pages, e.g., foo.html.zlib?

It's been a standard for a while. IE, Mozilla, Konqueror, etc, support it. It helps my little cable modem serve pages a little faster, since the objects with mime-type containing "text/" are compressed (and you can compress text a lot).

My patch also supports pre-compressed pages, ie if there's a request for a.html, and a.html.gz exists, it will send that one. With some cron action to make all of the compressed pages every night, the at-request-time compression goes away.

Ahh! I used up my mod points yesterday... Please someone mod the parent up -- this is really funny! And for those who don't get the reference...

Long version: http://www.acme.com/jef/netgems/scratch_monkey.htm l
Short version: http://www.tuxedo.org/~esr/jargon/html/entry/scrat ch-monkey.html

Some sites I'm familiar with have racks of 50 or more PCs running Apache or IIS just to serve a moderate traffic web site. If you do the math, you can see that two PCs can easily saturate an OC-3 line.

Both Apache and Netscape servers FORK a new PROCESS for every connection. Some others--including a compile option in Apache--start a new thread. Boa (and Jef's thttpd) don't. They're SINGLE THREADED. Just one giant "select" statement, and memory mapped files.

I think part of the problem has been poor education and lack of experience of "web developers." Many times, it would be worth the time to develop a custom high-performance non-threading/forking server to serve a site. This way you can do everything off of two PCs (in case one fails) instead of 50. We need to start encourging people with strong C++/Systems/Embedded programming experience to be our web developers, and not hire kids who's experience is limited to Java, Perl, or some proprietarty web middleware language. Imagine if you customize Boa to server the dynalic pages you need, with all assets coming out of RAM. You may pay an extra $100K or so for software development up front, but the hosting costs will recover that.

Cool! (Sorry, I'm a sucker for Cold War History - might I also recommend The Bureau of Atomic Tourism"> as a vacation planning site?)

For the Bay Area, I recommend the nearby SF-88 Nike Missile Base. During the 60s, this was the last line of defence against incoming bombers - the entire system was dismantled after the signing of the ABM treaty, except for one site that was kept (mostly) intact for historical purposes.

Located just north of the Golden Gate Bridge, and open a couple of days a week, you'll get to stand on the launch platform and descend into the bay where the missiles were stored. When you're not standing on the platform, they can also raise the missiles into firing position.

The tour guides are informed and geeky - when they detect a fellow geek, most will be happy to show off the gear they've restored. Lots of analog computers, vaccuum tubes, and frighteningly-high voltages. Be sure to ask how the computers worked. You'll be amazed at the engineering.

> The tour includes the actual control room where launch codes were recieved, and the infamous red button & code book are kept. You can even push it..Doing so before 1983 would have meant a couple million people would die.. :)

Likewise, the control vans at the Nike Missile Base feature a Button. Pushing said button before 1973, would have taken out a squadron of incoming Soviet bombers 100+ miles away with either a conventionally-tipped or nuclear-tipped warhead, saving several million people :)

Less than two minutes down the road the launcher at SF-88L, is a second Nike launch site - SF-87L. Better known as the Marine Mammal Center, it now defends cute little seals and sea otters, and is also open to visitors daily.

The hike up to the radar platforms at SF-87C is a bit long, but affords a wonderful view of the Marin headlands. (In addition to some of the best views in the Bay Area, the whole area is full of historical artifacts, including abandoned artillery emplacements from the Spanish-American War, through World War I and II.)

Cool! (Sorry, I'm a sucker for Cold War History - might I also recommend The Bureau of Atomic Tourism"> as a vacation planning site?)

For the Bay Area, I recommend the nearby SF-88 Nike Missile Base. During the 60s, this was the last line of defence against incoming bombers - the entire system was dismantled after the signing of the ABM treaty, except for one site that was kept (mostly) intact for historical purposes.

Located just north of the Golden Gate Bridge, and open a couple of days a week, you'll get to stand on the launch platform and descend into the bay where the missiles were stored. When you're not standing on the platform, they can also raise the missiles into firing position.

The tour guides are informed and geeky - when they detect a fellow geek, most will be happy to show off the gear they've restored. Lots of analog computers, vaccuum tubes, and frighteningly-high voltages. Be sure to ask how the computers worked. You'll be amazed at the engineering.

> The tour includes the actual control room where launch codes were recieved, and the infamous red button & code book are kept. You can even push it..Doing so before 1983 would have meant a couple million people would die.. :)

Likewise, the control vans at the Nike Missile Base feature a Button. Pushing said button before 1973, would have taken out a squadron of incoming Soviet bombers 100+ miles away with either a conventionally-tipped or nuclear-tipped warhead, saving several million people :)

Less than two minutes down the road the launcher at SF-88L, is a second Nike launch site - SF-87L. Better known as the Marine Mammal Center, it now defends cute little seals and sea otters, and is also open to visitors daily.

The hike up to the radar platforms at SF-87C is a bit long, but affords a wonderful view of the Marin headlands. (In addition to some of the best views in the Bay Area, the whole area is full of historical artifacts, including abandoned artillery emplacements from the Spanish-American War, through World War I and II.)

Cool! (Sorry, I'm a sucker for Cold War History - might I also recommend The Bureau of Atomic Tourism"> as a vacation planning site?)

For the Bay Area, I recommend the nearby SF-88 Nike Missile Base. During the 60s, this was the last line of defence against incoming bombers - the entire system was dismantled after the signing of the ABM treaty, except for one site that was kept (mostly) intact for historical purposes.

Located just north of the Golden Gate Bridge, and open a couple of days a week, you'll get to stand on the launch platform and descend into the bay where the missiles were stored. When you're not standing on the platform, they can also raise the missiles into firing position.

The tour guides are informed and geeky - when they detect a fellow geek, most will be happy to show off the gear they've restored. Lots of analog computers, vaccuum tubes, and frighteningly-high voltages. Be sure to ask how the computers worked. You'll be amazed at the engineering.

> The tour includes the actual control room where launch codes were recieved, and the infamous red button & code book are kept. You can even push it..Doing so before 1983 would have meant a couple million people would die.. :)

Likewise, the control vans at the Nike Missile Base feature a Button. Pushing said button before 1973, would have taken out a squadron of incoming Soviet bombers 100+ miles away with either a conventionally-tipped or nuclear-tipped warhead, saving several million people :)

Less than two minutes down the road the launcher at SF-88L, is a second Nike launch site - SF-87L. Better known as the Marine Mammal Center, it now defends cute little seals and sea otters, and is also open to visitors daily.

The hike up to the radar platforms at SF-87C is a bit long, but affords a wonderful view of the Marin headlands. (In addition to some of the best views in the Bay Area, the whole area is full of historical artifacts, including abandoned artillery emplacements from the Spanish-American War, through World War I and II.)

You might try thttpd from ACME Labs. I've used it (also Boa) on several 486 and early pentium machines.

These are very, very different approaches to creating a scalable server.

See Non-blocking I/O is good for more background on what multiplexing is and why it is good.

• 39320D-R
• 39320-R
• 29320-R
• 29320LP-R

Here's a handy bandwidth chart for common components to bookmark for easy reference.

http://www.acme.com/jef/netgems/scratch_monkey.htm l

-calyxa

What about thttpd ?

Has anyone compared it with fnord?

And Yes, I know it hasn't been updated in awhile ( May, actually, from the timestamps in the tarball, referring to the beta version ), but maybe they don't feel need to update it for their purposes anymore. . .

If you notice at the top of their page "Current bandwidth usage: 208.28 kbit/s" This has been well under the 10 Mbps required to pump out about 5 Gigs an hour. I run adult sites and have three RaQ4 servers pushing an average of 20-30 Mbps each. Hardware is the last of your worries when running a high traffic site, as long as you don't bog the server down with database requests and you tune software for maximum performance, utilizing multi-Mbps is very easy. For static content you may also want to look into thttpd. We use it for some of our image serving and it works great.

We gave up on throttling. It just doesn't work. And not from a technical standpoint, either. If you are going to do throttling, then you need a web server that does real throttling. The only one I know of is Zeus. It does real throttling, letting you limit the total bandwidth for all of a user's sites to a bytes/sec value. No Apache modules do this. Even thttpd doesn't seem to get this right.

I assume that you want to limit bandwidth that your customers use because the bandwidth to your server(s) is limited (i.e. you don't have a 100mbit connect to the internet). In this case, Apache modules will not do what you want. Someone puts up a 10mb file. That file gets downloaded and uses up all of your outgoing bandwidth. While it is being downloaded, the Apache throttle module refuses other requests. This is obviously not what you want.

So suppose you end up using Zeus, or find some other way to do real throttling. Now what do you set the throttle speed to? 5gb over a month averages a little less than 2k/sec. Say you set it higher, like 20k/sec, and there are ten connections downloading that user's files (which can easily happen with certain browsers). What does the average clueless user or webmaster think? They don't understand throttling. They just think that the website is slow and that your service sucks.

We would throttle down user's sites when their bandwidth ran out. Customers did not understand that they had run out of bandwidth, even though they were notified via email. They just thought their sites were slow. We received a lot complaints about that.

We found that the best thing to do is to not throttle and to presell bandwidth cheap. Our different packages come with different amounts of bandwidth, ranging from 5gb to 180gb. After that, customers can purchase extra bandwidth (for $0.50/gb). Customers receive a notification via email when their bandwidth is running low and again when it is completely gone. When their bandwidth is gone, we redirect their sites to a page stating that they used up all their bandwidth.

This solution is simple and it works. Customers always know how much bandwidth they have left and can buy more at anytime. We never have to worry about users running up a huge bill and not paying it, since everything is prepaid.

It's nice to know there are others out there who know state machines are the One True Way =). Ideally you have exactly as many threads as CPUs, and use non-blocking state machines for everything. (and unless the CPUs need to share a great deal of information, use processes rather than threads to side-step cache contention and locking; communicate with pipes or shared memory)

Unfortunately this ideal is sometimes hard to achieve because non-blocking APIs are not always available. (e.g. there is no way to poll/select a pipe on Windows, and true asynchronous file I/O is still in the testing stages on Linux)

Keeping this on topic - there are plenty of HTTP servers out there with more sane concurrency models - thttpd is one of many... (I can't really fault Apache for making the choices they did; their goals are more standards conformance and portability than raw speed).

So, you could say "xyz.dom may only use 200kbps for *.mpg files".

thttpd is especially suited for serving static files; it is not an all purpose machine such as Apache.

You can find out more information at thttpd's homepage.

thttpd is the server to use. It's a lean, mean web-serving machine (low memory and cpu usage). It just does it's job really well. It's not as full of options as Apache, but sometimes, that's just not important.

Yeah, that's because Apache isn't the fastest kid on the block, especially under a heavy load - I'd love to find out how various web servers handle being slashdotted.

More stuff here.

I had never heard of thttpd ("tiny/turbo/throttling HTTP server") so I looked it up and thought that I would share.

Also the i845G and P4X333 chipsets. Check the ACME Boardfinder.

TUX is the main performance competitor to IIS.

Uh, no. That would be iPlanet, thttpd and Zeus.. Especially Zeus.

TUX is a cute proof-of-concept, and if RH can get some leverage over MS by patenting it, I'm all for it. But let's not kid ourselves about who IIS' competitors are.

Or thttpd...

Even though, arguably, even thttpd has too many features :-)