Home  /  RSS  /  RSS Comments  /  Enter

Nginx? No thank you... Lighttpd

Nginx is 3rd (or 2nd depending on the statistics) most popular web server. It seems that it should be one of the best servers around however, every time I have to deal with it I understand that I really don't like it.

When you look deep down into the Nginx web server you realize that it not as good as you think it is. Even though, it is a good reverse proxy and very well suited for serving static files, when it comes to dynamic content it begins to feel sloppy.

It is not uncommon that you have a web site powered by nginx and in reality it works like a load balancer or reverse proxy in front of Apache or other services.

And this is not an accident, this popular webs sever has too many flaws:

• First of all it is not capable to handle CGI scripts at all.

• It does not support automatic control of a lifetime of FastCGI and SCGI processes.

  Basically this means that you need to prepare a separate services to run your FastCGI application instead giving this simple job to a web server.

• FastCGI support was broken for a long time and only recently we got an option to setup a CGI variable PATH_INFO correctly as required by CGI RFC.

  Before that you need to do some tricks with rewriting and you could not get url-decoded PATH_INFO as required by RFC.

• SCGI support is totally broken as:

  • It requires from the SCGI server to send full HTTP headers instead of parsing Status header.
  • PATH_INFO and SCRIPT_NAME do not work in the same way they were not working with fastcgi.

• Basic security feature like Options -FollowSymLinks that is implemented in all normal web servers starting from a "fat" Apache to a small and tiny thttpd is not implemented!

  Short explanation: consider Alice that creates a symbolic link such that it points to /var/users/passwords file. Alice does not have permissions to read this file but web sever may have such permissions. By creating an innocent symbolic link in the document root of her web server it escalates her abilities to read any file that the web server can read.

  Every modern web server has an option to track symbolic links and prevent serving files outside of the scope of the web server document root, but nginx does not have one.

• The documentation quality is overall lower then the quality of documents of Lighttpd or Apache web servers. Also the configuration is generally much more complicated and verbose even for simple tasks.

I've worked with nginx in different configurations and what I get most of the times is a feeling that the development of this web server is not performed according to protocol specifications but rather according what feature is needed as this specific point.

For example, it was mentioned in nginx source code that "Apache' specific PATH_INFO feature was not implemented. While PATH_INFO is a standardized environment variable defined by CGI 1.1 specifications and is not some "web server specific feature"

I know such note may look petty, but this is the general feeling of the level of implementation of many features.

---

So despite the popularity of this web server I would not choose it for serving dynamic content. If I need a high quality lightweight web server I'd always choose Lighttpd

• It has a similar asynchronous design as nginx has.
• It is very well suited for dynamic content and supports CGI, HTTP, FastCGI and SCGI protocols. The development version supports Tomcat's AJP13 protocol as well.
• It is very well documented and has a rich set of modules.

Before you jump and say:

Buy lighttpd leaks!

I'll answer: "not true, it does not leak". It is one of the well know urban legends on the Internet.

Quoting:

there are no memory leaks just stupid ways to use lighttpd.

e.g. it is really stupid to stream large files via a fastcgi app, when x-lighttpd-send-file could do a much more efficient job.

For further reading:

• http://redmine.lighttpd.net/issues/758
• http://redmine.lighttpd.net/boards/2/topics/4009

So if you consider using Nginx on your web site, I'd strongly recommend to take a look on Lighttpd first.

CppBlog and Wiki++ are officially released

I had released the cppblog and wikipp latest versions based on CppCMS 1.x.x. Latest versions can be downloaded from the sourceforge. They are available under GPLv3 license.

The documentation on building these two web applications can be found there:

• Wiki++
• CppBlog

If you are want to use one of these applications in your language you are welcome to get the pot files from these project translate them and submit them to me. I'll happily add them to the trunk.

The project moved to the new web server and domain name

Please update your RSS feeds and bookmarks:

• Project's main web site: http://cppcms.com
• Project's blog: http://blog.cppcms.com
• Project author's blog (Hebrew): http://artyom.cppcms.com

If you find any broken links, please report it to me.

CppCMS Project Receives Donations...

CppCMS project receives monetary donations using sourceforge donation system.

If you are using this project consider donating some money. Follow the donations button on the CppCMS projects web site or the button in this post.

The money would help to create a better product and provide better service to the CppCMS users community.

CppCMS and STLPort

I was interest to take a look in STLPort for a long time ago and recently I finally did it.

STLPort is a cross platform and "cross compiler" implementation of the standard C++ library. It has more permissive license then libstdc++ and frequently used when C++ developers want to use same code across different platforms and compiler vendors.

It is quite simple to use it instead of libstdc++ with gcc:

g++ -I /usr/include/stlport file.cpp -lstlport

So I tried CppCMS with it and was stuck with two STLPort library bugs:

• The operator | for std::ctype_base::mask enumerator was not defined as required by the standard. For example if I want to define a mask like alpha|digit the compiler rejected the code. I had only one such place in the code so I did a small workaround for the problem.

• The other problem was that some advanced localization code could not link. After searching the problem for some time I had found that some symbols that should be public where hidden.

  GCC allows to hide all-but marked linker symbols using -fvisibility=hidden parameter. This gives a developer an ability to mark library's public API with a special attribute and let the linker know which symbols should be kept public in the shared object and which shouldn't.

  The problem was that some essential but rarely used symbols had remained hidden.

  So in order to fix the issue I downloaded the source package of the library:

    apt-get source stlport5.2
  

  Removed the -fvisibility=hidden flag from gcc.mak file that was optional in any case and rebuild it with simple

    fakeroot dpkg-buildpackage
  

  It solved the problem for me. The bug was reported upstream and fixed in the 5.x branch.

So how do you build CppCMS with STLPort? Simple:

1. Fix the -fvisibility=hidden problem as shown above.
2. Configure CppCMS with an option -DUSE_STLPORT=ON -DDISABLE_STD_LOCALE=ON, thats it.

Note, the STLPort support is still experimental and due to some issues with STLPort library it is recommended to remove std localization backend from the library.

Pages

• About This Project

Categories

• Progress
• Storage
• Benchmarks
• Templates
• FastCGI
• Framework
• Cache
• Berkeley DB
• Comet
• Unicode and Localization
• Off Topic