symfony/symfony — pull request #6766 by KingCrunch (2013-01-16 20:41:22+00:00)
Title: [HttpKernel][HttpCache][RFC] SSI kernel proxy

Bug fix: no
Feature addition: yes
Backwards compatibility break: possible
Deprecations: possible
Fixes the following tickets: ~
Todo: see below
License of the code: MIT
Documentation PR: ~

Yes this is my second pull request about SSI-implementation (third, if you count the closed pre-`HttpKernel`-refactoring PR), but I came to the conclusion, that it could be more appropiate to separate `HttpCache` and the substitution of the include tags from each other, but before I put to much effort in an unwanted idea, I want to hear some opinions.

- Separation of concerns: `HttpCache` can concentrate on its purpose. Therefore I would separate the esi-substitution too. This should make both easier to maintain
- The substitution is useable without the cache, for example as a fallback, or for development, where caching is not wanted.

As a sideeffect `HttpCache` (when used) will cache the original content including the ssi-tag and the parsing of the tag will occur on every request. But we can get rid of `eval()` :wink:

// with cache
$kernel = new SsiKernelProxy(new AppCache($kernel);
// without cache (just subsitute)
$kernel = new SsiKernelProxy($kernel);

The first commit contains the SSI rendering strategy, which is exactly the same as in my other PR.

The second commit is the single class `SsiKernelProxy`. When ESI should be separated too I would rewrite it into a `IncludeKernelProxy`-class, which consumes one or more `IncludeSubstitutionStrategy`-objects, that handles the differences.

$kernel = new SsiKernelProxy(new AppCache($kernel,
array(new SsiSubstitutionStrategy,new EsiSubstitutionStrategy)
);

TODO
----
- For now the proxy doesn't respect any `Surrogate-*`-header. It should
- When from a server a `Surrogate-Capability` with the corresponding value (I guess `SSI/1.0`?) is set, this proxy should passthrou the request without handling, so it act as a fallback
- I would like to handle `maxage` and `s-maxage` separately:

$maxage = min($maxages);
$sMaxage = $shared ? min($sMaxAge) : 0;

In the current esi-implementation `maxage` is always set to `0`, but when I get it right it is more probably, that a on this way constructed page is private, than that it is public.