Four-Part Spec
The ESI specification was published as a World Wide Web Consortium (W3C) note in August. It actually includes four areas of specification:
1. Language Specification defines ESI 1.0, the Edge Side Includes language, which allows a page to be assembled by reverse proxies that understand the ESI language. ESI 1.0 is an in-markup XML (Extensible Markup Language)-based language.
2. ESI Invalidation Protocol offers the methods used to invalidate (expire) data on the edge by the origin server.
3. Architecture specification details the use of HTTP intermediaries to control content.
4. JESI (Java ESI) Tag Library Specification is intended to be the convenient JSP application-level interface to the ESI tags for Web caching functionality. Its purpose is to help in the use of ESI tags within a JSP application.
What ESI Does
ESI provides a mechanism for moving as much dynamic content processing as possible to the edge of the network.
The basic premise behind ESI revolves around templates, which are stored on the origin server and contain what the ESI specification calls fragments--dynamic content that may or may not be cachable and is marked appropriately using ESI tags. Each fragment is treated as an individual object, much in the same way images, Flash and Java applets are treated as separate objects. Each object has properties, including its own cache and access profile.
Some objects may be cached for hours, others minutes and some not at all. So rather than regenerate an entire page because the time changed or a small news item was added, the ESI system needs to fetch only the new piece of the Web page, which can be subsequently handled by the cache until it also expires.
An example page may appear as (numbers added for clarity):
- <html><head><title>
An example ESI template></title><body>
- <esi:try>
- <esi:attempt>
- <esi:include src="www.
mysite.com/myad.html" onerror="continue" />
- </esi:attempt>
- <esi:except>
- Write some HTML for the ad instead
- </esi:except>
- </esi:try>
- static content
- </body></html>
Let's take a look at these lines to examine how ESI works.
Line 2: This ESI tag specifies that the ESI processor should try to include some dynamic content. The only valid subtags, or children, of the try tag are attempt and except. Developers may notice that this closely resembles the try..catch..finally pattern of exception handling in languages such as Java and C++.
Lines 3, 4 and 5: These tags instruct the processor to attempt to fetch a fragment. Note that the tag is properly closed as per XML document rules. The onerror attribute of the include tag instructs the ESI processor to gracefully delete the error message that may be returned and to continue processing the page.
Lines 6, 7 and 8: These tags indicate what action should occur if the fragment specified in the attempt tag cannot be loaded.
Line 9: Again, the try tag is properly closed.
Lines 10 and 11: Other content, including additional fragments or native markup, may be included.
There are multiple tags that offer the capability of dealing with conditional situations. For example, cookies and user-agent header processing could be used to determine what type of content should be delivered to the browser.
So How Does ESI Help?
Let's examine today's solution. A Web page, containing breaking news, is generated by the origin server via a server-side language, such as ASP, JSP or PHP. This page is tagged as noncachable because the news item may change.
A Request Today
1. A browser makes a request for the page.
2. The originating server must process the request and serve the content. (The request may be directed through a series of network devices before it reaches the origin server. The end result, however, is the same regardless of the path through the network--the origin server must serve the page because it is dynamic).
You can see where this leads. Each request is treated the same, with the origin server assembling and serving the content to the browser. With ESI, the process is quite different since the news item is now an ESI fragment.
A Request With ESI
1. A first browser makes a request for the page.
2. The ESI processor looks to see if the page is in the cache. It if is, the processor pulls the template and parses the document. The processor then determines whether the ESI fragment for the news item either is not in the cache, in which case the processor will request it from the origin server, or is in the cache, in which case the processor may examine the TTL (time to live) and other headers indicating the freshness of the fragment. The entire page is assembled and served to the browser.
ESI also provides a mechanism, through the invalidation protocol, for content-management systems to invalidate objects stored on ESI processors throughout the network. This means content can be updated as needed.
The Language Specification
The ESI language specification is an XML-based language to be interposed into current markup (HTML, XML and so on) to provide logic and dispatch services. These tags are intended to be processed after they have been retrieved by the origin server but before they are processed by the browser. This means two things:
1. The pages served by the origin server are not valid, because they contain content that is not meant to be read by a browser.
2. The pages served by the origin server may contain native markup, such as HTML, that will not exist when the page is ultimately received and processed by the browser.
Many other types of in-markup language are in use today, such as PHP and SSI (Server Side Includes). ESI will not replace these languages, but it should nicely complement current technologies for handling dynamic content. There is one concern here, however: When ESI is processed by the same device as another markup, such as SSI, a mechanism must be put in place to determine which markup has precedence.
The first version of the ESI language includes the following functionality:
1. The ability to generate a page by assembling included content.
2. Support for variables. ESI 1.0 specifies variable use based on HTTP request headers, much as CGI does.
3. Conditional processing. Conditional logic with boolean comparisons can determine how a template is processed.
4. Exception and error handling. ESI offers the ability to provide alternative and default resources for a number of different situations.
ESI comprises elements, which are XML in an ESI-specific XML namespace. ESI processors parse but do not process elements outside of the ESI namespace. After processing by an ESI processor, the ESI elements are stripped from the output. Some ESI elements may contain other markup, such as HTML or other XML, while others may not.
For more information on the ESI language specification, see www.edge-delivery.com/language_spec_1-0.html.
Technology editor Lori MacVittie has been a software developer and a network administrator. Most recently, she was a member of the technical architecture team for a global transportation and logistics organization. Send your comments on this article to her at lmacvittie@nwc.com.
REPORTS
ANALYTICS
Follow 
