Contrib.social

HTTP_HOST is not a reliable default prefix

Open on Drupal.org →
Created on 31 July 2017, about 7 years ago
Updated 5 August 2024, about 1 month ago

By default, the apc module attempts to set a unique cache prefix based on the HTTP host of a request. There are three issues with this behaviour:

  1. HTTP 1.0 requests do not set HTTP_HOST, so the cache for such requests ends up with the prefix being an empty string.
  2. By default, Drupal's cache is per database instance, not multisite. It's possible to have a single configuration path map to different databases, or for multiple configuration paths to map to the same database.
  3. Related to this is that many simple sites don't bother with drush aliases or passing in --uri. That means that browser requests might hit www.example.com, but drush commands run with HTTP_HOST set to 'default'. This causes cache sync issues, and is most obvious when enabling or disabling modules. For example, disable a module with permissions through drush, but notice that the permissions are still shown in the UI's permissions list.

Points 2 and 3 were reported and addressed in the redis cache module here: #2252969: HTTP_HOST is not a reliable default prefix →

I propose we copy the redis solution for this and use as a default prefix a hash of the database hostname, database name, and prefix.

🐛 Bug report
Status

Fixed

Version

1.0

Component

Code

Created by

davidsickmiller

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024