Basic Frontend / Page Cache¶

• Target Audience: users who browse the frontend of a Neos website
• Responsible: Robert Lemke
• Implemented by: Robert Lemke
• Amount: 15 work days
• Version: must have for 1.0
• Planned Implementation Timeframe: March - April 2013

Motivation¶

Neos does not, so far, provide any sort of page cache. The has been from the beginning to rely on established HTTP mechanisms instead and use cache control directives and mechanisms like Edge Side Includes instead. The advantage of this approach is to not re-invent front end caching and being able to delegate this to highly performant proxies like Varnish.

Neos should, however, be production ready as is, without the need for a reverse proxy. Therefore Flow should provide a basic reverse proxy itself and thus be able to cache responses if no Varnish is used. As a first step, Flow has been refactored in 2011 / 2012 to provide or more modular bootstrap and an HTTP foundation. What's missing now is the actual usage of cache headers in Neos and a rudimentary reverse proxy integrated into Flow (and thus used by Neos).

Goal¶

Implement a reverse proxy for TYPO3 Flow which can basically cache HTTP responses according to the mechanisms specified in RFC 2616 and deliver them to a client if a cached response is available. The reverse proxy should also support purging / banning of single or multiple cache entries – this mechanism can then be used by Neos for invalidating cache entries of pages which have been modified.

Deliverables¶

• MUST: Reverse Proxy for TYPO3 Flow which can basically cache HTTP responses and return them on request
• MUST: Neos sets cache control headers / expiry times according to some global configuration
• MUST: Reverse Proxy allows for purging / banning single or multiple cache entries
• MUST: Documentation
• COULD: E-Tag Support
• MAYBE: Edge Side Includes support