Stateless Blog

Update: Happy to have found an existing solution to this problem

I’ve been promoting ESI as a serious consideration for anyone building scalable web apps for a while now, and reading mnot’s recent post about ESI prompted me to think about ways we can make ESI more efficient.

Something I think would be highly beneficial is a new HTTP header for marking responses as edge-processable. This would create additional visibility which intermediaries can use to avoid processing responses that require no attention.

As it stands; an ESI intermediary has to inspect the body of all passing responses, since it has no way of telling whether or not they include any esi elements that need processing*. Adding a standardised header would allow an ESI mechanism to skip all responses unless they are explicitly marked for esi processing, i.e. something like so:

> GET /some_page

< 200 OK
< Content-Type: text/html
< .....
< Edge-Process: ESI

Such a header, and a registry, would allow for other edge processing mechanisms to be introduced without each needing its own specific method of making itself visible.

* URI pattern rules are a strategy that will work to a point but has the downside of being brittle and a pita to manage.

I’ve just spent a decent chunk of my Sunday pulling together the new winter time table data for the latest update to the Jersey Bus iPhone app.. it was riveting stuff!

My good mate @robdudley has already asked for the data so he can use it in a web app he’s building, and I guess it could be useful for others in the future; so I’ve put it up as json in a gist on github so that you won’t have to go through the same tedium of compiling it yourselves.

The object structure should be relatively self explanatory, any questions about it leave a comment either on this post, the gist, or @mikekelly85