Я создаю SPA с внешним интерфейсом, размещенным на S3, и внутренним интерфейсом, обслуживаемым Lambda и API Gateway. Я пытаюсь использовать CloudFront, чтобы сидеть перед S3 и API Gateway, чтобы использовать одно и то же доменное имя, чтобы избежать проблем с CORS, и использовать файлы cookie без атрибута Domain.
Однако я CloudFront n00b, и в CloudFront есть некоторые особенности кэширования, которых я не понимаю.
По какой-то причине некоторые запросы API, сделанные от клиента, получают ответ 403, но этот запрос не попадает в Lambda - ответ выглядит как кешированный ответ CloudFront об ошибке. Самая странная часть заключается в том, что ответ об ошибке не является даже самым последним ответом, полученным с этого (или любого) URL-адреса. Тело ответа для 403 ответов соответствует тому, что мой сервер API отправил бы для неаутентифицированных запросов, отправленных на /api/*.
Вот запросы XHR, которые делает клиент: 
All of these API calls (including /api/activities/history/) have a cache-control header in the response that I thought would be preventing any of these responses from being cached at all:
cache-control: max-age=0, no-cache, no-store, must-revalidate, private
If it helps, the last response received by the client contains an x-cache header from CloudFront: x-cache: Error from cloudfront.
And here are the requests received by the origin:
[12/Jul/2020:19:44:16 +0000] "GET /api/user/ HTTP/1.1" 200 29 "" "Amazon CloudFront" 0/10.349
[12/Jul/2020:19:44:18 +0000] "GET /api/activities/history/ HTTP/1.1" 200 2036 "" "Amazon CloudFront" 0/1819.5900000000001
[12/Jul/2020:19:44:29 +0000] "GET /api/activities/in-progress/ HTTP/1.1" 200 139 "" "Amazon CloudFront" 0/3773.864
[12/Jul/2020:19:44:50 +0000] "GET /logout/ HTTP/1.1" 302 0 "" "Amazon CloudFront" 0/23.132
Forbidden: /api/user/
[12/Jul/2020:19:44:51 +0000] "GET /api/user/ HTTP/1.1" 403 58 "" "Amazon CloudFront" 0/1.839
[12/Jul/2020:19:45:12 +0000] "GET /login/github/ HTTP/1.1" 302 0 "" "Amazon CloudFront" 0/5.914
[12/Jul/2020:19:45:15 +0000] "GET /complete/github/ HTTP/1.1" 302 0 "" "Amazon CloudFront" 0/2289.144
[12/Jul/2020:19:45:16 +0000] "GET /api/user/ HTTP/1.1" 200 29 "" "Amazon CloudFront" 0/4.989999999999999
[12/Jul/2020:19:45:17 +0000] "GET /api/activities/in-progress/ HTTP/1.1" 200 139 "" "Amazon CloudFront" 0/714.226
You'll notice that the 403 response for /api/activities/history/ doesn't appear here. FYI the /logout/, /login/github/, /complete/github/ requests are from the same client, but are document requests from the client, which is why they don't appear in the screenshot above.
To add a little bit more detail to what is going on above, when the frontend loads it makes a request to the /api/user/ API endpoint. If the request is authenticated, then the frontend makes simultaneous requests to /api/activities/in-progress/ and /api/activities/history/. Otherwise, the user is presented with a login page. In the session shown above, I am able to render the main page fully, then I logout, load the main page and receive a 403 from /api/user/ rendering the login page. Then I click the login button, get redirected to Github, get redirected back, and then receive a 200 from /api/user/ generating simultaneous requests to /api/activities/in-progress/ and /api/activities/history/. The last API request is the one that fails, but shouldn't.
Here are the CloudFront behaviour settings for /api/*:
As you can see I am using the origin's cache headers.
I also created a custom error response for 403 responses to prevent caching of those responses:
Страницы ошибок CloudFront
Есть идеи, почему я должен получать кешированный ответ 403 на запросы к /api/activities/history/, когда последний ответ от этой конечной точки API был 200?
Извините за длинный вопрос , но большое спасибо за чтение!
РЕДАКТИРОВАТЬ: Я обнаружил, что одновременные запросы API кажутся центральными в этой проблеме. Если я изменю интерфейс c, чтобы запросы выполнялись последовательно, то все запросы доходят до лямбды, как и ожидалось.