- Newest
- Most votes
- Most comments
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
Relevant content
- asked 3 years ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated 8 months ago