@Paul:

My tests on 5.3.3 reveal that you get different fragment URIs for different pages ONLY if you call the pages after you specify a siteaccess. So, if I call:

http://53ezdemo.com/13011/page1/

...and:

http://53ezdemo.com/13011/page2/

I'll get the same fragment URI. However, if I call:

http://53ezdemo.com/eng/13011/page1/

...and:

http://53ezdemo.com/eng/13011/page2/

I'll get different fragment URIs. So, this could be considered an extension of what was reported originally here, and therefore treated as an enhancement, or as a new bug altogether, pretty much like EZP-21695. What do you think?

Might be related to EZP-23834 also?

Hi

Using URIElement, pathinfo property is mandatory to be able to build correct links within ESI calls. This is inherent to URI siteaccess matching.

Hi

Sharing ESIs across siteaccesses is not possible by design since HTTP cache always rely on URI for a given host. When rendering an ESI tag, the current SiteAccess must be serialized with its matcher, in order to be able to recompute links within this ESI call. Matchers indeed contain too much information, like pathinfo which prevents ESIs to be shared among different pages (within the same SiteAccess).
If you use siteaccesses, you more than likely have different settings (e.g. languages), which makes it share completely unpredictable. Moreover, sharing ESIs across different siteaccesses would be a nightmare when it comes to cache invalidation.

In short, I admit that there is an issue with ESI sharing across pages and inside the same SiteAccess (see EZP-23834 to follow this issue), but not with sharing across different SiteAccesses for the reasons explained above.

Thanks.

Doc issue: limitation described above needs to be documented.

Added a note on the page : https://doc.ez.no/display/EZP/Context+aware+HTTP+cache#ContextawareHTTPcache-Feature

QA Approved