First, that's great to see that implementing a new rendering strategy is now really easy. For the rest, I'm not sur what's the best strategy, given that I'm not sure that SSI will used often or not. Depending on the answer to this question, the way we implement it should probably be different.

How could you know if mod_include is enabled?

If it's not and I render a page, I will miss some parts, whereas ESI detects the reverse proxy presence

@alexandresalome Well, thats exactly the problem 😄 I use PHPs builtin webserver for quick development and it is obviously not aware of neither SSI, nor ESI. This gives me either the pure tags, or an error, that the rendering strategy does not exists.

That the cache itself propogates its abilities is quite nice, but to keep it simple I thought about, that enabled = false could always use the default strategy, instead of disable the ssi-strategy completely, but this (as far as I can see) cannot update the HTTP cache-headers?

A "more complete" idea: Currently HttpCache receives a Esi directly through the constructor. To me it sounds useful, when the rendering strategy can add a custom CacheFilter (name may vary) to HttpCache itself once it was used, or use DIC-tags, to receive all available cace filters. This will (for every added filter)

• Test, wether the frontend is capable to handle the strategy (at least in case of ESI)
• Depending on the result replace the test with the content
• Manipulate the headers (Add Surrogate-Control if required/useful, change cache headers, ...)

This is (slightly), what the Esi-implementation does right now. The change would be, that Esi is not directly injected during instanciation, but later added, if required, and (I assume) it would simplify the current Esi filtering, as well as adding new (custom) filters later.

interface CacheFilter; // equivalent of EsiResponseCacheStrategyInterface
class EsiCacheFilter implements CacheFilter; // Formerly EsiResponseCacheStrategy
class SsiCacheFilter implements CacheFilter;

This will probably require bigger changes... If there are no bigger objections, I think I'll have a least a look at it later.

A question at the end: What do you think, would it be useful to integrate the substition as ResponseFilter instead of CacheFilter directly into the kernel without the need for HttpCache? At the end it seems it's all more about "including" and "substitution", instead of caching, which is covered by "other parts" (Varnish, Nginx, Apache and HttpCache-class too). I want to say "substitute yes/no?" in Kernel, Caching of the several parts (without further testing about the capabilites) in Cache. And event-listener may work too?

@kingcrunch the great thing about the HttpCache currently is that it never triggers the booting of the real kernel (and so the creation of the container) in case of cache hits. Doing the caching inside the kernel itself would make it far less efficient as you would have to boot the kernel all the time.

@stof Of course, thanks, I completely missed this and it makes some parts my latest comment invalid 😉 What I'm playing around right now works like the Esi-implementation after all, but it seems it requires some bc-breaks... I'll come with an update I guess next weekend, or earlier, if I find some time.

Something different, that comes into my mind while digging through the code: There is the default-rendering strategy. Did I get it right, that it completely ignores any cache headers from a subrequest? Is this useful? When Esi falls back to the default strategy, this may break caching in a way, where non-cacheable (or short-living) parts were integrated into a public and long-living page, or not?

any news about ssi rendering strategy? All PR with it are closed.