Cache-control replaced by "no cache" by using CloudFront

0

Our web application generator output headers in a sample as shown below.

We return a cache-control header with a large value, but it is replaced by no-cache.

I don't get why?

The direct GET direct URL is:

https://app-online.cloud/apps/c3d3fc02-4ed8-4c22-ae21-ffc69af79c82/databases/e4a5beef-d7a2-4972-8f9d-4a53fd0edcd9/modules/c3de71b2-6c08-45a2-901a-1379c3d8dbbb/app/sites

and returns headers:

  • cache-control: max-age2592000,s-max-age=2592001,public
  • content-encoding: gzip
  • content-length: 1463
  • content-type: text/html
  • date: Sat 05 Sep 2020 18:26:54 GMT
  • etag: 656f9fc7f168eb9ef72a9ba0047340dc
  • server: Microsoft-IIS/10.0
  • status: 200
  • strict-transport-security: max-age=2592000
  • vary: Accept-Encoding

When CloudFront is inserted, the URL is https://openarchivaris.nl/app/sites and the headers are:

  • cache-control: no-cache
  • content-encoding: gzip
  • content-length: 1498
  • content-type: text/html
  • date: Sat, 05 Sep 2020 18:29:51 GMT
  • etag: 656f9fc7f168eb9ef72a9ba0047340dc
  • expires: -1
  • pragma: no-cache
  • server: Microsoft-IIS/10.0
  • status: 304
  • strict-transport-security: max-age=2592000
  • vary: Accept-Encoding
  • via: 1.1 32e4d419823b7f8df8417a8b18c9602d.cloudfront.net (CloudFront)
  • x-amz-cf-id: odc8jGb0jtxwZpalNEAhG7J4HeFQANvgqdJtSBYVm3HzTXjBJpfGGg==
  • x-amz-cf-pop: FRA50-C1
  • x-cache: Miss from cloudfront

The cloudfront behavior has no Lambda@Edge, cache based on selected request headers "None", object caching: use origin cache headers, no forwarding of cookies, no query stirng forwarding.

Origin has HTTPS only and adds a fixed authorization header/value.

Edited by: Guido Leenders on Sep 5, 2020 8:48 PM

asked 4 years ago1511 views
1 Answer
0

Found solution.

The (public) website is run as part of a .net core web application. That one uses the default response cache settings. However, to set up an asp.net core session, a cookie is exchanged. This cookie never reached the client (browser) due to the cache policies.

First test was to replace the cache-control on origin-response using Lambda@edge:

'use strict';

exports.handler = (event, context, callback) => {
const response = event.Records[0].cf.response;

if(response.headers\['cache-control'])  
{  
    response.headers\['cache-control'] = \[{   
        key:   'Cache-Control',   
        value: 'public, max-age=604800, no-cache="Set-Cookie"'  
    }];  
}  

callback(null, response);  

};

When applying this code in combination with forwarding of the .AspNetCore.Session cookie, the response times on subsequent GETs dropped from say 150 ms to 20 ms. And when served from client cache to 1 ms. Works fine. Note that both the setting of cache control as well as forwarding the ASP.Net cookie is necessary.

We tweaked the response cache on asp.net core by something like:

CacheControlHeaderValue cc = new CacheControlHeaderValue()
{ Public = true
, NoCache = true
, MaxAge = TimeSpan.FromSeconds(ControllerUtility.Public1DayCacheProfileDuration)
, NoCacheHeaders = { new StringSegment("Set-Cookie") }
};

context.HttpContext.Response.GetTypedHeaders().CacheControl = cc;

After this change, and WITH forwarding of the ASP.Net cookie enabled, the first user will load the public website pages into CloudFront from where next users will be served.

For more details: see https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Cookies.html

answered 4 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions