[MAGNOLIA-7725] Allowing caching for error page Created: 20/Feb/20  Updated: 07/Apr/20

Status: Open
Project: Magnolia
Component/s: None
Affects Version/s: 5.7.5
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Jonathan Ayala Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

It would be good to preserve cache-control headers when redirecting to error pages. This way it would be possible to take load off Magnolia by caching error-pages (404..)

Detailed requirements from SUPPORT-10809 are:

  • Retain original response headers in case of sendError, or
  • Make sure we can set Custom Response Headers in case of sendError (404, 500, etc) which are then used with a custom error page
  • (side but related topic) ensure that status code is retained across request (-> in the ContentTypeFilter, the StatusSniffingResponseWrapper always sets this status to 200 even when it's a 404!!)
  • ensure that Cache Voters (browserCachePolicy & cachePolicies) are executed for 404 requests so that they can properly vote for TTLs


 Comments   
Comment by Horst L [ 01/Apr/20 ]

@Jonathan Ayla

Is it possible to extend this ticket to 301 and 302 responses?

Currently it is not possible to include cache control headers for these responses either. But for our deployment scenario it would be helpful if we could also provide certain headers for these responses.
Currently we are bypassing this problem by using a patched CacheResponseWrapper class, in which we have changed the order of the method calls of the replayHeadersAndStatus() method.

// order of method calls changed, so that custom headers are applied to all responses processed by this method
@Override
public void replayHeadersAndStatus(HttpServletResponse target) throws IOException {
    //FIXME Start changed order of calls to write headers first
    target.setStatus(super.getStatus());

    final Iterator it = super.getHeaders().keySet().iterator();
    while (it.hasNext()) {
        final String header = (String) it.next();

        final Collection values = (Collection) super.getHeaders().get(header);
        final Iterator valIt = values.iterator();
        while (valIt.hasNext()) {
            final Object val = valIt.next();
            RequestHeaderUtil.setHeader(target, header, val);
        }
    }

    target.setContentType(super.getContentType());
    target.setCharacterEncoding(super.getCharacterEncoding());
    target.setContentLength(super.getContentLength());

    if (super.isError()) {
        if (errorMsg != null) {
            target.sendError(super.getStatus(), errorMsg);
        } else {
            target.sendError(super.getStatus());
        }
    } else if (super.getRedirectionLocation() != null) {
        target.sendRedirect(super.getRedirectionLocation());
    } else {
        target.setStatus(super.getStatus());
    }
    // FIXME End
}

Is there a reason why for 302 reposes the headers set in Magnolia is only applied after the response has already been sent?

 

 

Generated at Mon Feb 12 04:26:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.