Thanks again for this implementation, and alignment with Akamai 5.0 as per this PR.
I've noticed a difference between this and ESI processing on Akamai (using https://hub.docker.com/r/akamaiesi/ets-docker as a harness) in regards to the Akamai-specific REQUEST_PATH variable, now supported, and wondered if worth aligning?
It seems that REQUEST_PATH retains a value throughout nesting, whereas with Akamai it represents the path of each include.
e.g. a document hosted at /original:
<!DOCTYPE html>
<html lang="en">
<body>
<p><esi:include src="/path/to/fragment" dca="esi" /></p>
</body>
<html>with /path/to/fragment containing:
<esi:vars>$(REQUEST_PATH)</esi:vars>
In Akamai, the output would include:
<p> /path/to/fragment </p>
But fastly/esi would retain the inbound path, and output:
This might be confusing for consumers expecting a strict "subset of Akamai ESI 5.0".
Thanks again for this implementation, and alignment with Akamai 5.0 as per this PR.
I've noticed a difference between this and ESI processing on Akamai (using https://hub.docker.com/r/akamaiesi/ets-docker as a harness) in regards to the Akamai-specific
REQUEST_PATHvariable, now supported, and wondered if worth aligning?It seems that
REQUEST_PATHretains a value throughout nesting, whereas with Akamai it represents the path of each include.e.g. a document hosted at
/original:with
/path/to/fragmentcontaining:In Akamai, the output would include:
But
fastly/esiwould retain the inbound path, and output:This might be confusing for consumers expecting a strict "subset of Akamai ESI 5.0".