- Newest
- Most votes
- Most comments
Not sure why HTTP APIs behave differently but it seems as if CORS settings don't work out to well with Lambda integrations. Going to go with this solution mentioned here on stackoverflow which involves me including an additional OPTIONS
route for all my endpoints. I will look around a few docs just to make sure the correct default headers are applied properly. Hopefully, some one here can give me details as to how Http APIs differ from Rest APIs when it comes to CORS whether you are using a proxy or non-proxy integration.
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-cors.html
The link above states that I can use a proxy route (OPTIONS /{proxy+}
) with a Lambda integration in order to handle all CORS preflight requests without my authorizer getting in the way. Going to try this and see if it works.
hey,
do you have access-control-allow-origin
on your request header while you accessing the API gateway. Although you have configured the CORS at API Gateway level, you will get an error if the local application environment or your Postman doesn't support the CORS.
Let me know if you have any questions
Relevant content
- asked a year ago
- asked 2 years ago
- asked 6 months ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 20 days ago
I added that header to my local request and it still doesn't work. Should I include an
OPTIONS
route handler for my Lambda function? I'm starting to think I have to manually return the correct headers from my lambda. Although, that seems to not be right. You would think I wouldn't have to. Doesn't API Gateway create anOPTIONS */endpoint
route for you?