Day 12 - welcome to handlers land

For those of you who are really planning to have a close look at nginx and the way it works, there is one thing you should know: this thing is modular to hell (some would say too much for its own good, but that's another story). And modularity is achieved using something a lot of people don't like: pointers to functions. This is a standard way to have a bit of "object-oriented-like-interface-implementation" in C but this is not the most common C and a lot of people get scared by these constructs.

Quite honestly, I cannot say this:

typedef char *(*ngx_conf_handler_pt)(ngx_conf_t *cf,
    ngx_command_t *dummy, void *conf);

is the kind of C I find very easy to read. On the other hand it's much more concise than the Java way where you basically have to define an interface and a class implementing this interface (hello java.lang.Comparable) just to provide a basic function.

So, just a warning: the C in nginx is not for the faint of heart. And given there is practically no comment to be found in the code, you should really consider getting back to your C courses if, like me, you haven't practiced in a few years.

So, I was mentioning handlers as they are pretty much everywhere. In particular, they are the foundation on which all modules are built. For a good idea of what kind of behavior you can change by implementing a module, you should read Valery's post on HTTP request processing phases.

Now, you might notice agentzh comment on NGX_AGAIN/NGX_DONE interpretation. Even Valery was not completely up to date with this. Now, what is really funny, is agentzh post: why nginx does not have an API reference. Even the core developers consider their baby good enough to commit to an API. I guess that's why it's still version 0.X.

Now, the scary part: more than 20M domains are running this...