Some common questions about Edge Side Includes

After my REST in (a mobile) peace talk at the WHYMCA in Milan, 2 weeks ago, I was surrounded by a few developers trying better understand how does Edge Side Includes behave: after I realized that some concepts are not so “standard”, here’s a parade of little things to know about ESI.

Is it a single-construct language?

No: although the most used tag is the include one:

Typical ESI tag
<esi:include src="" />

the ESI specification has a plethora of commands, while the Oracle website has a specific section on more detailed insights.

If I install Varnish and use ESI, do I need to do something specific?

No: after you set up Varnish in order to do ESI processing, everything will magically happen :)

Do I need, in my architecture, an ESI processor?

Yes, otherwise the ESI tags won’t be replaced.

Luckily, Varnish and Squid do it for free since years: the RAD framework for PHP Symfony2 implements a custom-made reverse proxy and something is moving also in the Ruby ecosystem.

Does it work with modern browsers?

No: since ESI never got hype browser vendors never thought about implementing the specification.

The topic is also subject of various arguments.

Does ESI invalidate my output format?

No: since ESI processors ( like Varnish ) work on the server side, before sending the response to the clients esi tags get replaced with the actual content.

Does it work with HTML?

Well, the specification works regardless the format of your response: it can be application/xml, json, html, a custom media type…

How do I avoid my middleware to look for ESI tags in every response?

Parsing responses, in order to look for ESI tags, is expensive, we all know.

In order to let your ESI processor ignore responses not containing ESI tags you can specify a declination of your content type:

HTTP response with profile parameter in the media type
HTTP/1.1 200 OK
Content-Type: application/xhtml+xml;profile=esi

and make your processor checking this profile attribute.

Unfortunately, it seems that only the application/xhtml+xml supports the profile attribute, but you can “hack” the media type of your needs and make it support it, since you are working on the server side, without sending non-standardized media type descriptions over the internet.

How does my application know if it can send ESI tags or not?

There are 2 common scenarios:

In order to take this decision a custom HTTP header is used: Surrogate-Capability, which has been introduced in the edge side architectures specification.

Is ESI a new technology?

10 years old, baby :)

Hi there! I recently wrote an ebook on web application security, currently sold on leanpub, the Amazon Kindle store and gumroad.

It contains 160+ pages of content dedicated to securing web applications and improving your security awareness when building web apps, with chapters ranging from explaining how to secure HTTP cookies with the right flags to understanding why it is important to consider joining a bug bounty program.

Feel free to skim through some of the free chapters published on this blog and, if the content seems interesting enough to you, grab a copy on leanpub, the Amazon Kindle store, gumroad or simply checkout right down below!

Buy the Web Application Security ebook for $9.99

In the mood for some more reading?

...or check the archives.