Don’t reduce dispatcher testing to an afterthought

Frankly speaking, dispatcher usually does not receive much attention when it comes to testing. In most cases configuration updates get inspected only on the go without any regression tests being triggered alongside.

Neglected dispatcher may lead to application issues that often slip through unnoticed across lower level environments and surface right after production deployment.

Overlooked dispatcher testing doesn’t come out of nowhere - it’s neither straightforward nor easy to implement a reliable test suite for it. Moreover, dispatcher is often not verbose enough and all its surroundings would have to be mocked out to test it in isolation.

This talk will describe various techniques (man-in-the-middle proxying, mocking strategies, configuration tricks, CI/CD pipeline examples, etc) to let you test and promote your dispatcher config with confidence.

Henry Kuijpers

Are you also thinking of setting up Dispatcher /filter testing? To for example check the security checklist, the known vulnerable URLs, etc. etc.?


Small addition to what I already answered on stage - when testing filters, allowed query params, etc you can inspect one of these special headers I mentioned during my talk - you're gonna find "not cacheable because of query param X" or "blocked by filter Y" information there.

Tomasz S

Do you think it would be better to let CDN deal with gzip, etags etc? Is dispatcher the best place for it? I guess you wanted it there to optimize the traffic between cdn and apache as well?

Konrad Windszus

AFAIK Fastly generates ETags by default for AEMaaCS if they are missing from the origin response


Wouldn't it be easier if Adobe just clear the cache from the Cloud Manager Pipeline (after running the functional tests) and then start the cache-warmup?


Warmup service pre-populates dispatcher cache with objects upon instance start and functional tests get started afterwards, so that'd defeat the purpose of the warmup. Adobe's working on an alternative approach to functional test execution (these .net domains won't be used at all).

Henry Kuijpers

What is that default domain / where can we find that setting (OSGi console)?

Andres Bott

reach out to me, i can give you some details

Andres Bott

for the time being, please also do not block the .net domains in dispatcher config

Alexander Berndt

Did I understand correctly, that your workflow was more: Detect Incident, analyze it, reproduce it in this clean test-environment, fix it, and eventually keep the tests in the CI pipeline. Otherwise I would find it hard to identify test cases upfront. In real life problems are way more complicated than someone could imagine.


All these incidents I mentioned resulted in Apache config adjustments/fixes and effectively were the main driver towards dispatcher testing. Initially we focused on these burning cases, but at the end of the day all existing Apache/dispatcher features were retrospectively covered with tests. I personally don't find it that hard to identify test cases, but your milage may vary (it boils down to how you manage your dispatcher configuration).

Henry Kuijpers

Are you thinking of open-sourcing this as a full-fledged testing library for everyone to use?

(see answer in talk video)