The ESI Project consists of a few building blocks for supporting ESI. Who knows what it will turn in to. For now all we have is a simple HTTP test bed. = HTTP Testbed = For now we haven't got any source or binary releases but the source is available for svn access from svn://www.escenic.org/escenic/trunk/esi/testbed/ {{{ svn co svn://projects.linpro.no/escenic/trunk/esi/testbed/ cd testbed mvn package }}} Maven will create {{{target/testbed.war}}} which is the actual test bed. The {{{testbed.war}}} file can be deployed in any web application container supporting servlet 2.4 and the front page describes how to use the web app. Go to the home page of the web app for further documentation. If you just want to browse the source, use the subversion [http://www.escenic.org/browser/trunk/esi/testbed/ browser]. The functionality of the testbed is described in the web app itself: [http://www.escenic.org/browser/trunk/esi/testbed/src/main/webapp/index.html] Put simply the HTTP testbed allows you to PUT content to a flat, directoryless file system, and GET them again from a number of special directories. For example you can PUT /hello.txt with some text, and you can GET /etag/hello.txt and you will get the same content back but complete with working ETags. It can check HTTP1.0 and HTTP1.1 conditionals, can send Cache-Control response headers, and most importantly, understands Surrogate-Capability and responds with appropriate Surrogate-Control headers. You can also get it to simulate sloooooww origin servers and to randomly (or coordinated) return any HTTP error code you want. The testbed is designed to make it easy to write integration tests for HTTP proxies like [http://varnish-cache.org/ Varnish Cache] and for other HTTP clients, such as RSS readers or web browsers and test their conformance to various parts of HTTP. == To Do's == Use trac to track this? === Show how to use it === Make a small maven project that shows how to use this beast in an integration test, e.g. httpcache4j or varnish (could test ESI support). === Content Negotiation === (opened as ticket 5) Make it possible to upload several representations and identify which representation should be used for which combinations of conneg, and then trigger that conneg. e.g. {{{ PUT /conneg/content-type/text/plain/something.txt "something" PUT /conneg/content-type/application/xhtml+xml/something.txt "

something

" }}} something.txt would then support conneg using the Accept header: GET /conneg/something.txt would always have "Vary: Accept" Likewise, {{{ PUT /conneg/language/en/content-type/text/plain/something.txt "yes" PUT /conneg/language/en/content-type/application/xhtml+xml/something.txt "

yes

" PUT /conneg/language/fr/content-type/text/plain/something.txt "oui" PUT /conneg/language/fr/content-type/application/xhtml+xml/something.txt "

oui

" }}} Here the conneg filter would know that the response is keyed on both Accept-Language and Accept. GET /conneg/something.txt would return a "Vary: Accept, Accept-Language". === Vary based on user agents === Make it possible to tell the server that the response should vary based on user agents, possibly via a regex: {{{ PUT /conneg/user-agent/.*Googlebot.*/something.txt "Googlebot content" PUT /conneg/user-agent/.*MSIE.*/something.txt "MSIE content" PUT /conneg/user-agent/.*/something.txt "Other content" }}} GET /conneg/something.txt would in this case add "Vary: User-Agent" and perform the regexes to find the first one that matches. === Replace Error Filter === (Perhaps need to rethink this) Replace Error filter with Status Code filter, and allow injection of specific return headers. For example do this towards the back end: {{{ PUT /something.txt X-Location: http://localhost:8080/cc/etag/something.txt ------- 200 OK }}} Then you can get something.txt from the {{{header}}} and {{{redirect}}} directories: {{{ GET /header,Location/redirect,301/something.txt ------- 301 MOVED PERMANENTLY Location: http://localhost:8080/cc/etag/something.txt }}} The header directive will echo the {{{X-Location}}} header (sans {{{X-}}}), and the redirect will issue a redirect. This can allow us to check a HTTP client honours redirects. By accessing e.g {{{/cc,3600/header,Location/redirect,302/something.txt}}} you could verify that your cache implementation actually caches HTTP 302 redirects. === pattern, rate parameters === Make the "pattern" and "rate" parameters work for sleep and perhaps other filters, not just error. === Gzip and deflate === GET /gzip/something.txt will do conneg and compress the response if allowed === Authentication === Make it possible to require logging in with a specific Authorization header === Jetty container === Make it run stand alone using jetty; {{{java -jar esi-testbed.jar}}} or maybe a maven goal