Links don't vary for single site with multiple hostnames

A patch for this issue. The approach is to vary the cache-id to distinguish between sites. This causes the favicon paths to mirror the hostnames they'll be retrieved from (e.g. https://example.com vs https://www.example.com) and avoid CORS errors on any manifest files.

Fixing this looks like it will also solve the problem with the domain module: #2968070: Support the domain module → .

@blairlearn is it still a problem?

It's looks like all links and metatags URLs are relative, so I can't see where the problem is exactly.

And changing the cache id won't change the pregenerated icons' URLs.

@mably Yes. This is still a problem.

The change to the cache-id varies it to include the hostname. On a site with multiple domains, e.g. example.com and www.example.com, you end up with the cache-id being responsive_favicons.example.com:icons or responsive_favicons.www.example.com:icons, depending on which was used for the request.

Our sites typically have four domain names, this patch has been serving us well for the past nine months.

I sadly still doesn't understand what the problem is exactly...

Are you using the Domain module ?

Our individual sites have multiple hostnames. Without going too deeply into it, we'll have something like mysite.example.org and mysite-prod.example.com pointed at the same instance. Among other things, this is useful for migrations where we want to be able to keep mysite.example.com pointed at the old server until all the content is ready to go live. (This is one scenario, we typically have as many as four names/domains pointed to a single site.)

The responsive favicons UI uses relative URL (e.g. /site.webmanifest), but these are rendered in the head block as absolute URLs, which are then cached. So if the first user to visit the site comes in via mysite.example.org, the URL for the manifest that will be cached is https://mysite.example.org/site.webmanifest.

The problem comes in when a user visits the site via any of the other hostnames. If the first visit is to mysite.example.org, anyone visiting mysite-prod.example.org will be served cached HTML with the manifest URL pointing to mysite.example.org instead of mysite-prod.example.org. This results in a CORS error.

Similarly, a reference to /favicon.svg will be cached as https://mysite.example.org/favicon.svg. (I don't recall for certain whether the favicons themselves result in CORS messages.

We are not using the domain module (though the similarities occurred to me as well after the patch was written). Our sites are hosted on Acquia, but I've been able to duplicate and debug the issue using host file entries that resolve to localhost.

Ok, thanks for your clarifcation, I think I get the idea.

On our side all the URLs are kept relatives on the page.

Is it mandatory on your side to have those absolute URLs?

This is interesting. My first thought was to wonder if we're both looking at the same code and the answer is, we are not.

I hadn't realized it until now, but the absolute URLs are a result of the patch for the subfolder issue 🐛 Incorrect path if Drupal is installed in subfolder Active . A previous developer had determined this was necessary because our hosting arrangement allows us to have "microsites" so that one Drupal site is served as a "subdirectory" of another. e.g. https://mysite.example.com/myothersite. (My understanding is that the hosting provider uses something based on "Drupal Gardens")

Thanks for your time in helping us understand what's going on.