A Functional View of A Web Server

Posted by on in Blogs
A few days ago, I opined that, "Web applications, as a class, are extremely easy to debug." I'm going to further explain why I think that is true by introducing a useful abstraction which you can employ when you are debugging a web application which doesn't seem to do what is is intended to do.

When a web application misbehaves, one of the first things you'll need to do is determine if the problem is in the browser/client (e.g., buggy JavaScript, attempting to use CSS on IE 6, etc.) or in the server application (e.g., returns incorrect HTML, inserts wrong data into database, etc.). In order to make this distinction, it is helpful to use a very simple conception of what a web application does. HTTP is a stateless protocol. Therefore, a web server is expected to always return the same results in response to a certain request, without regard to what has happened beforehand. So we can consider the server as a single function:

[caption id="attachment_38073" align="alignnone" width="500" caption=" "](Browser request, state) -> web server -> result (usually HTML)[/caption]

The illustration above may appear a bit strange, because of the close proximity of the browser and the database server. In reality, we know that the database server is likely closer to the web server than to the browser. But remember, I am attempting to treat the web server as a pure function here (I'll explain why in a minute). The state of the database, if there is one, will certainly affect the page returned by the web server. Therefore, it is an input to the function. Similarly, authentication, which can also change the page returned by the web application is most often stored in a cookie. So cookies are also inputs to the server function.

Using this abstraction, it is now very easy to diagnose where the bug exists, by looking at the inputs to the function and its result:

  • If the inputs are correct and the result is wrong, then the bug is in the server. But remember that "result" means the HTML returned by the server, not the manner in which the browser renders it. It is possible for correct HTML to be rendered incorrectly, especially if JavaScript or IE 6 are involved.

  • If the inputs are incorrect, then the bug is obvious. But remember, inputs can include things like form data which, for some reason, people don't always tend to examine.

  • If the inputs and the result are both correct, but the page still looks wrong in the browser, then the bug is in the browser/client side.

The only circumstance in which this abstraction doesn't really work is when you're maintaining state on the client. An example would be when using frames. If you click a link which targets a frame, the result that you see in the browser will be different depending upon what you have done before, because you might have other pages open in other frames. This is an example of why I think that frames are not a good architectural fit with the rest of the web.

Once you've determined eactly where the bug lives, you are well on your way to fixing it. You can also describe the bug with more precision. For example, you will say things like "the server returns incorrect HTML (incorrect style on the div with ID 'foo') when..." instead of "the panel is on the wrong place in the page when...".


It's not really relevant to the rest of the post, but here is how I made the illustration above. I decided the post would be easier to understand if I included a diagram of the function. So I followed my standard process for using Microsoft Visio, which is something along the lines of the following:

  1. Decide that I need a very simple block diagram, and remember that this is something which Visio is supposed to be good at.

  2. Attempt to use Visio to produce the diagram.

  3. "WTF, I'm not allowed to resize this? I thought that Visio was supposed to be for simple drawings."

  4. Decide, "Wow, I'd forgotten how much I really despise Visio."

  5. Produce diagram in some other piece of software.

  6. Repeat, 6 months later. Some day I'll learn.

I ended up using Inkscape, which has more than a few rough edges, but which was good enough to produce a simple diagram, which is more than I can personally say for Visio. The drawing includes an MPLed globe image, so I'm releasing the whole drawing under the terms of the MPL.


Check out more tips and tricks in this development video: