Expires header not set

Created on 20 April 2018, over 6 years ago
Updated 20 October 2023, about 1 year ago

Hello,

Thank you very much for the module.

Max-age is set in the cache header but the Expires header is not set so the page_cache module set the cache permanently anyway.

Maybe it is the same problem as πŸ’¬ Page cache isn't invalidated Needs review

I will upload a patch.

πŸ› Bug report
Status

Needs review

Version

1.0

Component

Code

Created by

πŸ‡«πŸ‡·France Grimreaper France πŸ‡«πŸ‡·

Live updates comments and jobs are added and updated live.

Missing content requested by

πŸ‡¦πŸ‡ΊAustralia dpi
about 1 year ago
Sign in to follow issues

Comments & Activities

  • Issue created by @Grimreaper
  • πŸ‡«πŸ‡·France Grimreaper France πŸ‡«πŸ‡·

    Here is the patch.

    Thanks for the review.

  • πŸ‡«πŸ‡·France Grimreaper France πŸ‡«πŸ‡·

    Same patch but made against the 8.x-1.0-alpha1 tag.

  • πŸ‡«πŸ‡·France Grimreaper France πŸ‡«πŸ‡·

    Sorry, I had not tested the dependency injection. Here are two new patches that do it properly.

  • πŸ‡ΊπŸ‡ΈUnited States mark_fullmer Tucson

    The previous patches weren't in the right format to be apply-able; I've recreated the same changes in the attached patch. I've also verified the fix, though I'll forego RTBC'ing this, since I'm adding a patch now.

    For future reference, a quick manual verification of this (in the absence of automated tests) is below:

    /**
     * Implements hook_ENTITY_TYPE_view_alter().
     */
    function my_module_block_content_view_alter(array &$build, BlockContentInterface $entity, EntityViewDisplayInterface $display) {
        // Add 'max age' to bubble up expiration via custom event subscriber.
        $build['#cache']['max-age'] = '30';
    }
    

    A content block placed on a page will yield the following:

    .... while a page without that block (assuming a global TTL set to "60" will show:

    Importantly, I think this "Expires" behavior was not the original intent of the module (rather, it was intended for reverse proxies & edge caches; however, I think there are valid use cases for letting the "Expires" value bubble up to the Internal Page Cache's cache_page bin, as this change accomplishes (e.g., a widget that is responsible for retrieving external content every X minutes).

  • πŸ‡¬πŸ‡§United Kingdom Leon Kessler

    I don't see why this patch should not be incorporated into the project. Yes most people will be using this module with an external cache/CDN, and probably have the internal page cache module uninstalled.

    However, for those that need to use the page_cache module, it's either this patch, or patching Drupal core with https://www.drupal.org/project/drupal/issues/2352009#comment-14064154 β†’ (which is the latest patch on that issue at this current time).

    I don't believe there is any harm in setting the correct Expires header, but I suppose there could be some unexpected consequences for someones setup (although you could argue if this does cause an issue for someone, it's a symptom of a bug in their infrastructure, rather than with the Drupal instance itself).

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 10.1.x + Environment: PHP 8.1 & MariaDB 10.3.22
    last update over 1 year ago
    4 pass
  • πŸ‡¦πŸ‡ΊAustralia Feng-Shui

    Re-roll against 2.x.

  • πŸ‡«πŸ‡·France prudloff Lille

    We should probably decide which patch to keep between πŸ› Expires header not set Needs review and πŸ’¬ Page cache isn't invalidated Needs review .

Production build 0.71.5 2024