By using AWS re:Post, you agree to the Terms of Use

Questions tagged with Caching

Sort by most recent
  • 1
  • 2
  • 12 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Managed-CachingOptimized not caching file

I have set a behavior for "/robots.txt". It comes before than the default behavior (precedence). **Cache policy** name is **Managed-CachingOptimized**. **Origin request policy** name is not set (empty). **Response headers policy** name is not set (empty). This is a pretty standard setting for caching. Cloudfront origin is ELB for EC2. But Cloudfront is not caching the static text file. There is no **x-cache** information on response headers (hit from Cloudfront or miss from Cloudfront). Here are the response headers: ``` accept-ranges: bytes content-encoding: gzip content-length: 430 content-type: text/plain date: Wed, 24 Aug 2022 03:19:41 GMT etag: "38e-5e3c786e719d0-gzip" last-modified: Thu, 14 Jul 2022 17:49:44 GMT server: Apache/2.4.54 (Ubuntu) set-cookie: AWSALB=ZJcMr4JytpQ5+YBldD+ytbG2n855hylXciCYrcZ2hfQeJDaiz3KgBQn7ALjo+BpsZd5SHKN4c9u/zFQ9oXolGHEqVQZTBQ6K9FUWaICEh6JFQVefjwE1oiiZ0qnI; Expires=Wed, 31 Aug 2022 03:19:41 GMT; Path=/ set-cookie: AWSALBCORS=ZJcMr4JytpQ5+YBldD+ytbG2n855hylXciCYrcZ2hfQeJDaiz3KgBQn7ALjo+BpsZd5SHKN4c9u/zFQ9oXolGHEqVQZTBQ6K9FUWaICEh6JFQVefjwE1oiiZ0qnI; Expires=Wed, 31 Aug 2022 03:19:41 GMT; Path=/; SameSite=None; Secure vary: Accept-Encoding ``` Here are the request headers: ``` :authority: fisiculturismo.com.br :method: GET :path: /robots.txt :scheme: https accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 accept-encoding: gzip, deflate, br accept-language: en-US,en;q=0.9 cache-control: no-cache cookie: __gads=ID=62782a8f5a755c77-222f0dc46e7c004b:T=1656794055:RT=1656794055:S=ALNI_MZqlDHMRjqwWm8dbUOgnXV24kmbUg; ips4_device_key=75b924dcdd29d88a78f9c1f395ca5f66; ips4_forum_view=table; ips4_notificationMenuShown=1659848309910; _ga=GA1.3.334719718.1660926268; _gid=GA1.3.682253330.1661275622; ips4_hasJS=true; __gpi=UID=0000073c0158a521:T=1656794055:RT=1661275623:S=ALNI_MYpOpUI6AcXcKskOFNUnNYr4WbIiw; ips4_IPSSessionFront=bd8bigqv1ops6dg8t0908dloh7; ips4_ipsTimezone=America/Sao_Paulo; AWSALB=4NY1ew2QGqkW4EzEz5z++28mVVUN40npwXy8/zsx21tXGepo9aBFaFUdBJVv+s9rC2342LRKOT74PqryKTKDMpUfOGorDsLd5s8/R55cmVQDOF0VSm+oOqD8EfR2; AWSALBCORS=4NY1ew2QGqkW4EzEz5z++28mVVUN40npwXy8/zsx21tXGepo9aBFaFUdBJVv+s9rC2342LRKOT74PqryKTKDMpUfOGorDsLd5s8/R55cmVQDOF0VSm+oOqD8EfR2 pragma: no-cache sec-ch-ua: ".Not/A)Brand";v="99", "Google Chrome";v="103", "Chromium";v="103" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "macOS" sec-fetch-dest: document sec-fetch-mode: navigate sec-fetch-site: none sec-fetch-user: ?1 upgrade-insecure-requests: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Safari/537.36 ``` What could be causing the issue?
1
answers
0
votes
29
views
asked a month ago
0
answers
0
votes
39
views
asked 2 months ago

API Gateway custom authorizer's caching configuration

Hey, I've created a custom authorizer to an API Gateway, and attached it to some relevant endpoints (same authorizer for multiple endpoints). The authorizer verifies a given JWT token against the *Auth0* service. The "Authorization Caching" was set to 5 minutes (default value), and the `identitySource` was set to the be the `Authorization` header, but while QAing the flow, some strange behavior occurred. The first problem is that for the first time sending a request I get a *200 response*, but for any subsequent (identical) request, I get *403 response* with this message: > User is not authorized to access this resource The second problem is that then I've tried to disable the "Authorization Caching", but it took **~24 hours** to this configuration modification to take effect. Once the Authorization Caching got disabled, every request got returned with a *200 response*. ___ This is the `policyDocument` gets returned when the user is successfully verified: ``` { Version: '2012-10-17', Statement: [{ Action: 'execute-api:Invoke', Effect: 'Allow', Resource: <resourceArn>, }] } ``` My questions are: 1. Is it possible that the "Authorization Caching" configuration is cached? - If so, what's the way to invalidate that? - If not, how come that modifying the configuration doesn't affect the behavior? 2. What can be the reason for the first problem where only the first request succeed any subsequent request fails? - Is it possible that the value provided to the `identitySource` (i.e. the cached value) has a maximum characters limit? Thanks in advance :) ps, if more information is needed, I'd be happy to share.
0
answers
0
votes
55
views
asked 3 months ago
  • 1
  • 2
  • 12 / page