-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OPTIONS endpoint does not invoke lambda code #1434
Comments
Looking into this - for some background, have you tried this on Lambda as well and seen a different result? |
@awood45 this is only an issue running sam local. When the template is run through cloudformation the api gateway properly invokes our Lambda. This is only an issue with testing locally - which is still a serious issue. |
@awood45 should this ticket be in https://github.com/awslabs/serverless-application-model/issues I was just trying to find this issue in that repo and realized there is aws-sam-cli and servereless-application-model |
As far as I can see the problem was introduced by #1242. In particular, the following added lines short-circuit all OPTIONS requests to the CORS behaviour. |
aws#1434 This is intended to get the following integration tests passing: tests/integration/local/start_api/test_start_api.py TestServiceCorsSwaggerRequests TestServiceCorsGlobalRequests Those tests use a [CorsConfiguration](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-corsconfiguration.html) and a [Cors Global](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html), respectively, to enable CORS. When CORS is enabled, OPTIONS requests should send a 200 with the specified CORS headers, even if no OPTIONS handler is explicitly stated in the pre-transformation SAM template. I confirmed this by deploying from a [SAM template](https://github.com/douglasnaphas/play-sam/tree/master/cors-swagger) similar to one of the failing integration tests (with Cors specified but with no explicit OPTIONS handler), and observing that it does indeed respond with a 200 and the CORS headers attached.
aws#1434 This is intended to get the following integration tests passing: tests/integration/local/start_api/test_start_api.py TestServiceCorsSwaggerRequests TestServiceCorsGlobalRequests Those tests use a [CorsConfiguration](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-corsconfiguration.html) and a [Cors Global](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html), respectively, to enable CORS. When CORS is enabled, OPTIONS requests should send a 200 with the specified CORS headers, even if no OPTIONS handler is explicitly stated in the pre-transformation SAM template. I confirmed this by deploying from a [SAM template](https://github.com/douglasnaphas/play-sam/tree/master/cors-swagger) similar to one of the failing integration tests (with Cors specified but with no explicit OPTIONS handler), and observing that it does indeed respond with a 200 and the CORS headers attached.
aws#1434 This is intended to get the following integration tests passing: tests/integration/local/start_api/test_start_api.py TestServiceCorsSwaggerRequests TestServiceCorsGlobalRequests Those tests use a [CorsConfiguration](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-corsconfiguration.html) and a [Cors Global](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html), respectively, to enable CORS. When CORS is enabled, OPTIONS requests should send a 200 with the specified CORS headers, even if no OPTIONS handler is explicitly stated in the pre-transformation SAM template. I confirmed this by deploying from a [SAM template](https://github.com/douglasnaphas/play-sam/tree/master/cors-swagger) similar to one of the failing integration tests (with Cors specified but with no explicit OPTIONS handler), and observing that it does indeed respond with a 200 and the CORS headers attached.
@gordonmleigh I pulled your commits into #1649 and was able to get the integration tests passing in that PR. |
douglasnaphas/aws-sam-cli#1 To see the problem with OPTIONS described in this Issue: 1. Make one directory where the branch for the PR addressing the issue is checked out, from the awslabs/aws-sam-cli repo (the PR dir). 1. Make another directory where the develop branch of the awslabs/aws-sam-cli repo is checked out (the develop dir). 1. In each of the above two dirs, activate a virtualenv for Python 3.7.4 and run `make init` to make a `samdev` executable available in each virtualenv. 1. In the PR dir, run `samdev local start-api --profile $PROFILE --template $PLAY-SAM/dev-template.yml --port 5000 --host localhost` 1. In the develop dir, run `samdev local start-api --profile $PROFILE --template $PLAY-SAM/dev-template.yml --port 5001 --host localhost` 1. In each dir, run `curl -X OPTIONS -i http://localhost:$PORT` where `$PORT` is 5000 or 5001, depending on the dir. 1. You should get a 200 with `"Output":"hello from options"}` as the response data from the Express server in the PR dir, 200 with no data in the develop dir. This illustrates the issue of OPTIONS not reaching the handler.
aws#1434 This adds an integration test to verify that templates with explicit OPTIONS handlers actually have those handlers invoked on OPTIONS requests. There has been an issue with OPTIONS requests returning 200 and not reaching an explicitly specified OPTIONS handler. aws#1649 fixes that, so if the integration test added in this commit passes (and fails on the develop branch), it could be added to that PR.
aws#1434 This adds an integration test to verify that templates with explicit OPTIONS handlers actually have those handlers invoked on OPTIONS requests. There has been an issue with OPTIONS requests returning 200 and not reaching an explicitly specified OPTIONS handler. aws#1649 fixes that, so if the integration test added in this commit passes (and fails on the develop branch), it could be added to that PR.
Was released in v0.42.0. Closing |
Not sure if I should create a new issue for it but I'm facing this on version |
Any update on this? still facing this issue on v1.100.0 |
Facing this issue too with v1.103.0 |
Description
We have implemented OPTIONS endpoints that do some CORS related processes. With the release of version 0.20.0 the OPTIONS endpoints return 200 without invoking the lambda functions.
Steps to reproduce
sam local start-api -p 3002
Observed result
Expected result
The expectation was that "invoked hello world" would be printed twice - once for the OPTIONS and once for the GET request.
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
sam --version
:SAM CLI, version 0.22.0
More details
Template File
hello/app.js
The text was updated successfully, but these errors were encountered: