All AEM as a Cloud Service skills: component development, Workflow model design, development, triggering, launchers, debugging, and triaging, Dispatcher config authoring, advisory, incident response, performance tuning, and security hardening, Rapid Development Environment (RDE) deployment, log inspection, snapshots, and troubleshooting via `aio aem rde`, Jackrabbit Oak query/index tuning (property, Lucene index definitions), and extracting/inventorying JCR queries (XPath, SQL2, QueryBuilder) across a codebase.
85%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Use this checklist before proposing or applying Dispatcher/HTTPD changes in AEMaaCS.
This guardrail is grounded in current cloud dispatcher configuration layouts, validator behavior, managed runtime defaults, and dispatcher/httpd semantics.
Treat dispatcher/src as the deployable config root (must contain conf.d and conf.dispatcher.d).
Do not edit cloud-managed defaults directly. Put customer intent in mutable wrappers:
conf.d/rewrites/rewrite.rules (includes default rewrite rules)conf.dispatcher.d/filters/filters.any (includes default filters)conf.dispatcher.d/cache/rules.any (includes default cache rules)conf.dispatcher.d/clientheaders/clientheaders.any (includes default clientheaders)conf.dispatcher.d/virtualhosts/virtualhosts.any (includes default virtualhosts)conf.d/available_vhosts/*.vhost and conf.dispatcher.d/available_farms/*.farmTreat these wrapper files as extension points, not replacement excuses. Preserve the include of the managed default unless there is a deliberate, evidence-backed reason to override the baseline:
conf.d/rewrites/rewrite.rules should keep default_rewrite.rulesconf.dispatcher.d/filters/filters.any should keep default_filters.anyconf.dispatcher.d/cache/rules.any should keep default_rules.anyconf.dispatcher.d/clientheaders/clientheaders.any should keep default_clientheaders.anyconf.dispatcher.d/virtualhosts/virtualhosts.any should keep default_virtualhosts.anyTreat these as cloud-managed defaults whose semantics should be preserved unless platform documentation explicitly says otherwise:
conf.d/dispatcher_vhost.confconf.dispatcher.d/dispatcher.anyconf.d/available_vhosts/default.vhostconf.dispatcher.d/available_farms/default.farmconf.d/dispatcher_vhost.confKeep these invariants intact for validator compatibility:
conf.dispatcher.d/dispatcher.any includes enabled_farms/*.farmconf.d/dispatcher_vhost.conf includes conf.d/enabled_vhosts/*.vhostconf.d/enabled_vhosts/*.vhost and conf.dispatcher.d/enabled_farms/*.farm are symlinks/clientheaders -> ../clientheaders/clientheaders.any/virtualhosts -> ../virtualhosts/virtualhosts.any/renders -> ../renders/default_renders.any/filter -> ../filters/filters.any/cache/rules -> ../cache/rules.any/cache/allowedClients -> ../cache/default_invalidate.any/cache/ignoreUrlParams -> ../cache/marketing_query_parameters.any or a wrapper file at the validator-supported customer include locationIf include topology changes, require explicit validator proof.
For cloud readiness, assume these checks are mandatory:
conf.dispatcher.d/enabled_farms/*.farm)conf.d/enabled_vhosts/*.vhost)ServerName "*" is invalid and fails validationfullServerAlias "*.adobeaemcloud.net" and ServerAlias "*.adobeaemcloud.com" are expected; currently warnings but treat as release blockersTypical failure signatures seen in validator testdata:
unable to find any farm in 'conf.dispatcher.d/enabled_farms'no file found for matching pattern: conf.d/enabled_vhosts/*.vhostincluded file (...) does not match any known fileServerName: ServerName directive is set to '*'statfileslevel: Statfileslevel set to -1... misconfigurationImportant cloud warning to treat as action item:
/ignoreUrlParams is not configured, validator warns about marketing parameter strategyDo not repurpose or rewrite over cloud-managed health and probe paths:
/system/probes/live/system/probes/start/system/probes/ready/system/probes/health/systemreadydispatcher_vhost.conf wires these paths for liveness, startup, readiness, and managed rewrite-map rollout behavior. Any vhost or rewrite customization must preserve their pass-through behavior and must not introduce redirects, auth gates, or filter denials on those endpoints.
When managed rewrite maps are enabled, readiness behavior depends on the rewrite-map readiness state. Do not assume redirect maps are active before readiness conditions are met.
Preserve cloud-managed vhost safety behavior as well:
conf.d/enabled_vhosts/*.vhostDo not remove or bypass these guards unless the user is intentionally working on those specific cloud-runtime behaviors and the change is validated end to end.
${DOCROOT}, ${AEM_IP}) over hardcoded absolute pathsPreserve these cloud defaults unless the change explicitly requires otherwise and the impact is proven:
AllowEncodedSlashes NoDecodeModMimeUsePathInfo OnDirectorySlash OffDispatcherUseProcessedURL OnDispatcherPassError 0DispatcherUseForwardedHost may be controlled by platform-provided configuration; treat host-forwarding behavior as a trust-boundary settingDispatcherRestrictUncacheableContent OnPreserve managed defaults in these extension surfaces unless the user is intentionally changing the feature:
default_clientheaders.any forwards critical headers such as Authorization, Cookie, Host, X-Forwarded-Proto, and x-request-iddefault_filters.any carries supported allow rules for CSRF token fetches, GraphQL, persisted queries, Forms, Screens, clientlibs, and selected commerce-related routesdefault_rules.any keeps known deny cache rules such as CSRF token responses and Screens channel JSONdefault_rewrite.rules includes protections such as X-Forwarded-For spoof blocking, common abusive path blocking (xmlrpc.php, wp-login), and the persisted-query ;.json pass-through rewrite used for cache file extension compatibilityManaged runtime behavior to respect:
CACHE_GRAPHQL_PERSISTED_QUERIES requires matching CORS and endpoint verification when enableddefault.farm enables serveStaleOnError, gracePeriod, and enableTTL by default; tune them deliberately, not accidentallyCloud-managed environment-sensitive routes also exist:
Do not classify these as unconditional vulnerabilities. Evaluate them by environment and by whether the behavior is intentional for the documented cloud baseline.
Design implication: do not depend on trace-level logging for production diagnostics.
Use Dispatcher/HTTPD for:
Use CDN configuration for:
When both are possible, document why one layer is chosen.
Minimum static evidence before sign-off:
validate({"config":"<changed dispatcher content>","type":"cloud"})lint({"mode":"directory","target":"<dispatcher src path>","strict_mode":true})sdk({"action":"check-files","config_path":"<dispatcher src path>"})sdk({"action":"diff-baseline","config_path":"<dispatcher src path>"}) for drift-sensitive changesWhen a local dispatcher validator is available, corroborate with:
validator full <dispatcher-src>validator httpd <dispatcher-src>validator dispatcher <dispatcher-src>When local SDK runtime verification is required, use local-sdk-execution.md to record the launcher mode and any non-default environment variables that affect local behavior.
Runtime evidence when behavior changed:
trace_request({"url":"<representative url>","config_path":"<dispatcher src path>"})inspect_cache({"url":"<representative cacheable url>","config_path":"<dispatcher src path>"})Also verify these cloud-specific invariants when relevant:
adobeaemcloud.net and adobeaemcloud.com alias coverageAlways include:
AEMaaCS)Reference docs:
.tessl-plugin
skills
aem-rde
aem-workflow
code-assessment
content-distribution
create-component
assets
references
dispatcher
incident-response
references
dispatcher-foundation
performance-tuning
references
dispatcher-foundation
security-hardening
references
dispatcher-foundation
technical-advisory
references
dispatcher-foundation
workflow-orchestrator
references
dispatcher-foundation
ensure-agents-md
references
migration
references
dispatcher
legacy-ui
template-modernization
validation
scripts
dispatcher-tool
validate-migration