We have a setup with 3 sites (say n.com, r.com, s.com). We use Akamai for caching which accesses our dispatchers by prefixing the domains with www-origin (for example Akamai accesses the dispatcher at www-origin.n.com to serve up www.n.com pages). Recently, when launching the latest site we saw that links using the Externalizer were not producing the right links for the 3rd site, instead of links being s.com the links were being linked as www-origin.s.com.
Our initial setup for /etc/map.prod.publish/https and /etc/map.prod.publish/http had entries for:
www-origin.n.com (with sling:internalRedirect for /content/n)
www-origin.r.com (with sling:internalRedirect for /content/r)
www-origin-s.com (with sling:internalRedirect for /content/s)
www.n.com (with sling:internalRedirect for /content/n)
After some troubleshooting we found that simply deleting the entries for www-origin-s.com fixed the issue for us (externalizer links were now return www.s.com for content within the /content/s/ structure instead of www-origin-s.com).
A couple questions for people with Multinenant setups and Akamai.
1) Are the entries for www-origin necessary for /etc/map as long as the dispatcher has the vhost setup properly?
2) If there are multiple entries in /etc/map for the same content path which entry takes precedence if the domain is not matched (for example when we were testing and accessing the publisher directly by IP, externalizer links were still returning www-origin-s.com)?
I see that you have mentioned 2 paths with etc/maps i.e.
/etc/map.prod.publish/https and /etc/map.prod.publish/http
You will not need the http and https protocol to be added in etc/maps and only https should be enough. If any requests that are being made with http, the same will be redirected to https (I believe you already have this in place) as we do not allow http access on production.
If v-host is configured to listen to www.n.com then you do not need etc/map.prod.publish/http.
Ideally there should not be multiple entries in /etc/map for the same content path. Even if it's present it will try to resolve to the latest rule that is added. The same can be verified using [HOST]:[PORT]/system/console/jcrresolver