Documentation

There are several important features of Cherokee that really do make a difference in real-world production environments.

Cherokee bundles a one of a kind GUI to set up every available feature without the need of editing any configuration files by hand. It is a modern and easy to manage web application that allows to set up the server with speed and ease. The interface is thoroughly documented throughout Cherokee’s documentation. Several security measures prevent non authorized personnel from accessing the application, and one-time passwords are generated each time the program is launched. This can be used to give temporary access to a remote administrator.

The Swiss-army knife of the Cherokee bundle. This little tool enables you, among other things, to rotate the logs with absolutely no downtime at all. No connections are lost. No delay happens. It can also be used to trace Cherokee’s state on the fly, even remotely and on production servers.

This tool has its own documentation under the cherokee-tweak section.

X-Sendfile is a special, non-standard HTTP header that has been supported by Cherokee for a while. At first you might think it is no big deal, but think again.It can be enabled in any CGI, FastCGI, SCGI, or uWSGI backend. Basically its job is to instruct the web server to ignore the content of the response and replace it by whatever is specified in the header. The main advantage of this is that it will be Cherokee the one serving the file, making use of all its optimizations. It is useful for processing script-output of e.g. php, perl, ruby or any cgi.

This is particularly useful because it hands the load to Cherokee, all the response headers from the backend are forwarded, the whole application uses a lot less resources and performs several times faster not having to worry about a task best suited for a web server.

You retain the ability to check for special privileges or dynamically deciding anything contemplated by your backend’s logic, you speed up things a lot while having more resources freed, and you can even specify the delivery of files outside of the web server’s document root path. Of course, this is to be done solely in controlled environments. In short, it offers a huge performance gain at absolutely no cost.

Note that the X-Sendfile feature also supports X-Accel-Redirect header, a similar feature offered by other web servers. This is to allow the migration of applications supporting it without having to make major code rewrites.

Of course, this feature can be enabled or disabled in a per-rule basis, so you can have several rules and handlers on your virtual servers with the feature ON or OFF according to your needs.

Cherokee has an ability hardly ever seen in any service delivering application, be it web content, multimedia streaming or almost any other server you can think of.

Whenever a configuration change is applied, it is immediately reflected in the web server with no downtime requirements to restart the server. Of course the connections that are already being served will continue normally with the same parameters that where negotiated with the requesting clients, but they will not be shut down just to perform a menial task such as restarting the server.

It’s a bit like changing the tires on your car while still driving.

In fact, this mechanism is not only limited to configuration updates. Cherokee is so smart that it can even apply this to perform full program upgrades. This means you can completely replace the binaries for new ones, launch the enhanced versions and yet not suffer any downtime. Zero connection losses, no lag associated. Guaranteed.

This might seem as just another cool feature, but is in fact huge. Just think about it: an extremely high traffic site cannot afford to be down. Ever. Not to upgrade the webserver. Not to enhance it. Not to reflect a new configuration setting. Thousands of hits per second depend on it.

With Cherokee you can cope with this and much more. With Cherokee, it’s easier done than said.

A problem arises when virtual hosts and SSL must be used simultaneously. This is due to the fact that a web server cannot see the hostname header when the SSL request is being processed. The first thing that the server has to do is to connect with the other end by using SSL/TLS. The user entered host part of the URI must match the Common Name (CN) provided by the certificate. Since virtual hosts are in use, the CN of the first available certificate may or may not match the one specified in the early stages of TLS negotiation.

Cherokee supports the clean and standard method of dealing with this issue called Server Name Indication (SNI) that sends the name of the virtual host during the TLS negotiation.

If SNI is supported by your SSL/TLS library, the SSL layer does not need to be restarted. Since the host info can be put in the SSL handshake, things will simply work as long as there is a web browser with SNI support at the other side. Currently every modern web browser supports this, and Cherokee has TLS SNI support for the OpenSSL backends.

Note that for SNI to work, client support is required. Web browsers known to support it are Mozilla Firefox 2.0+ and Opera 8.0+ in all its variants, Safari 3.2.1+ on OS X and Vista, Internet Explorer 7+ (Vista, not XP) or later, and Google Chrome (Vista, not XP).

When using SNI is not possible, other workarounds can still be used. Check the SSL recipe of our cookbook for more details.

Ever heard of the DB Access Layer, AKA DBSlayer?

In case you haven’t, DBSlayer is a database abstraction and pooling layer designed to be simple to use (it’s a DB abstraction layer for the web age built on top of HTTP and JSON).

Well, Cherokee ships our very own DBSlayer handler that provides the fastest implementation in existence. It also provides several interesting enhancements.

The usage of this balancing mechanism is a blessing when you wish to scale connection growth against the database layer without replicating your databases to every web server. It is also useful when you have problems like local connections overwhelming a local slave, local slave database failures, or replication failures.

This feature delivers connection pooling, database abstraction to enable easier migrations and administration, load balancing and automatic fail over.

Yes, that too! Cherokee also provides a state of the art HTTP reverse proxy module. Check the documentation for more details and give it a try.

And if that is not enough, you can always take a look at the rest of the modules bundled with Cherokee.

Both audio and video streaming are supported, intelligently handling the available bandwidth to maximize service. Are you planning on being the next Youtube? Take a look at the Streaming handler.

A pretty nifty feature that has been having great acceptance is Cherokee’s capability of generating temporal URLs to serve hidden file. The Hidden Downloads handler is exactly what you need if, for instance, you plan on serving lots of files and want to be protected against automatic download scripts. Of course that is not the sole use of this. Cherokee only implements the security. From there on, the sky is the limit.

These rule types have been fully implemented for a long time. The things achievable by these rules are at the same time very powerful and very complex. You can combine them with as much flexibility as you want.

Another interesting feature is a project aimed at providing configuration wizards as an easy way to deploy a set of standard applications. The idea is to select an application from the list and let the wizard configure Cherokee to be able to run such application -say Wordpress, for instance-.

Even though the obtained configuration could not be perfect, it will always be a good starting point to play with for further tuning.

Slowloris is the name of a perl-based HTTP client that can be used to perform DOS attacks on web servers. It uses a minimal amount of TCP traffic to do so, and quite frankly the attack has been running amok out in the wild with devastating effects for a lot of servers.

Guess what? Cherokee is resilient to Slowloris and is recommended as an effective defense on many security guides, such as the Slowloris DOS Mitigation Guide.

Cherokee-Admin uses RRDtool to collect and display statistical data. If this feature is enabled, you will access a wide variety of information. Check the usage graphs section for more details.

There is an advanced template subsystem used for both the Advanced Virtual Hosting module and the Custom logger.

These modules can perform macro substitution to provide fine-grained control over their capabilities. The template subsystem provides slicing support in pretty much the same way the Python syntax does, so it can basically allow to use portion of the replacement strings instead of the whole thing.

You can read more about the specifics of the syntax and practical examples on the config_virtual_servers_evhost.html#slicing[Slicing] section of the Advanced Virtual Hosting documentation.

Cherokee has built-in support for efficient caching mechanisms. These allow it to cache anything that passes by (whether static or dynamic content), without having to depend on an additional caching layer such as Squid or Varnish. Typically such layers inherently introduce latency due to the round-trips associated to checking whether or not the contents have already been cached. Since Cherokee can process all of this on its own, this overhead can be totally avoided. Check out the Front-line Cache documentation.