Option to configure Dynamic Content Assembly (DCA) defaults?

[TomStrepsil]

As a feature request, would it be possible to configure the default for the dca handling of <esi:include> found within streams?

This library now mirrors Akamai ESI 5.0, which supports dca defaults via Edge-Control: dca=esi response header, thus allows for control of this behaviour outside of markup.

The fastly JS library for ESI also defaults to recursive inclusion, and supports configurable depth - which might also be nice to configure here, too.

Once again, thanks for open sourcing this!

[vagetman]

@TomStrepsil Thanks for sending these issues. The wording default thrown me off a bit. I think we need 2 things here:

1. add a config option similar to Inherit the Processor Type of the Parent that Akamai has.
2. add support for Edge-Control headers, where dca=<mode> attribute sets the processing type.

The inheritance is probably what you're calling a "default". Further it reads

The default behavior is for fragments with no processor type specified to receive no processing at all. With this option set to “On,” fragments that have no processor type specified for them (either through the configuration file or response headers) inherit the processor type of the template page. If the processor type for the fragment is spec- ified in the response headers or in the configuration file, this option has no affect.

Would this address the issue you're having?

[TomStrepsil]

I believe Akamai supports these options for a property, as per the link:

1. Enable the ESI Processor
2. Enable through Response Headers
3. Detect and Deny ESI Injection

I guess option 1 was what I perhaps meant for "default". I believe with that setting in the property manager, ESI is processed, whether an Edge-Control header is produced upstream or not.

For 2, also without dca="esi" in the markup, ESI is processed in the document "by default" - unless dca="none" exists against the tag. Despite the EdgeSuite 5.0: ESI Developer’s Guide stating:

dca - The type of processing for object. The default is “none.”

As per the EdgeSuite 5.0: ESI Developer’s Guide:

you can specify to process a fragment with a specific method
...
The optional dca="none|esi|xslt|java|akamaizer" can be used in the include statement to specify a different type of processing

full quote:

DCA refers to Dynamic Content Assembly, and as an attribute it refers to the type of processing to be applied to the src or alt object. By default, an included object will be included as flat text. You can specify in your EdgeSuite configuration file to process a fragment in the same method as the template, or you can specify to process a fragment with a specific method such as ESI, XSLT, or None. The optional dca="none|esi|xslt|java|akamaizer" can be used in the include statement to specify a different type of processing: xslt for the EdgeSuite Transformations service, java to include an object processed through EdgeComputing for Java, akamaizer for the EdgeAkamaizer, or none for no dca processing.
You can daisy-chain processors by using the following syntax. Note the single quotes within the double-quotes around the “akamaizer->esi”. This is necessary so that the right arrow (->) isn’t seen by ESI to be the closing bracket.:

<esi:include src="obj.html" dca=”’akamaizer->esi’"/>

This statement means first parse and process the object with the EdgeAkamaizer, then process the output as ESI. You can daisy-chain the Akamaizer, XSLT, and ESI processors; you can daisy chain up to five processors total, in any order.

For 3, no attempt to use dca in markup for ESI will work.

[vagetman]

Hey @TomStrepsil, I'd like to run this by you to see if it would be what you wanted here.

Proposal: DCA Inheritance, Include Depth Limit & Edge-Control Header Support

I'd add three capabilities to address this issue:

default_dca: DcaMode (default: None) - controls how <esi:include> without an explicit dca attribute is processed. Set to Esi to get Akamai-style behavior where all fragments are ESI-processed by default. An explicit dca="none" on a tag still opts out.

max_include_depth: usize (default: 3) - safety limit on recursive ESI processing depth, matching the JS library.

Edge-Control header parsing - when processing a fragment response, parse the Edge-Control header for dca=esi or dca=none directives. This lets origins control per-fragment ESI processing via response headers, without markup changes. Header directives override the configuration default but are overridden by an explicit dca attribute on the tag.

Precedence (highest wins): tag attribute -> Edge-Control header -> Configuration.default_dca

// Current behavior (unchanged)
let config = Configuration::default();

// Akamai-style inheritance + depth limit
let config = Configuration::default()
    .with_default_dca(DcaMode::Esi)
    .with_max_include_depth(5);

Please let me know how does it sound. Thanks!

[TomStrepsil]

All sounds perfect to me! Would seem to align exactly with my experience of Akamai.

On the Edge-Control header point, you could consider supporting Surrogate-Control from the Edge Architecture Specification - there's a suggestion that Fastly already supports this, but it's listed as "proprietary to Fastly", so unclear if it's fully supported / the same thing.

I believe the spec is a join Akamai / Oracle thing, supported by Varnish cache - never quite made it as a standard, but would be intrigued to know as a stretch-goal whether controlling ESI processing could be activated using a Surrogate-Control: content="ESI/1.0" from origin, equally?