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

질문됨 4년 전1555회 조회
1개 답변
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

답변함 4년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠