[Question] Internal server error when request method OPTIONS

[miguelslemos]

Had anyone same issue? When I try via postman make a request method OPTIONS the response is
{"message": "Internal server error"} if I try in API Gateway Console, lambda Console, npm run local and npm run invoke-lambda the response is ok. Any idea what is the problem?

[miguelslemos]

Execution log for request test-request
Wed Apr 12 12:24:37 UTC 2017 : Starting execution for request: test-invoke-request
Wed Apr 12 12:24:37 UTC 2017 : HTTP Method: OPTIONS, Resource Path: /flowrates
Wed Apr 12 12:24:37 UTC 2017 : Method request path: {proxy=flowrates}
Wed Apr 12 12:24:37 UTC 2017 : Method request query string: {}
Wed Apr 12 12:24:37 UTC 2017 : Method request headers: {}
Wed Apr 12 12:24:37 UTC 2017 : Method request body before transformations: 
Wed Apr 12 12:24:37 UTC 2017 : Endpoint response body before transformations: 
Wed Apr 12 12:24:37 UTC 2017 : Endpoint response headers: {}
Wed Apr 12 12:24:37 UTC 2017 : Method response body after transformations: {}

Wed Apr 12 12:24:37 UTC 2017 : Method response headers: {Access-Control-Allow-Origin=*, Access-Control-Allow-Methods=POST,GET,OPTIONS, Access-Control-Allow-Headers=Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token, Content-Type=application/json}
Wed Apr 12 12:24:37 UTC 2017 : Successfully completed execution
Wed Apr 12 12:24:37 UTC 2017 : Method completed with status: 200

[vitalii-budkevych]

OPTIONS works just fine for me from postman. Couple potential reasons for "Internal server error":

1. Stage you're calling from postman has deployment that differs from current version of the API invoked by test invoke and perhaps OPTIONS method doesn't exist in the deployment on the stage.
2. Your postman request includes some unexpected headers and/or doesn't include expected headers. Something like {"Content-Type":"application/x-www-form-urlencoded"} instead of {"Content-Type":"application/json"}

[miguelslemos]

everything is ok, only way to stop {"message": "Internal server error"} is remove options from simple-proxy-api

[dinvlad]

Any way to resolve it? I've tried setting up options exactly as in the example, but still getting the same error. I suspect it has something to do with binary support. I.e. if I remove the binary types from the API, OPTIONS starts to work correctly. If I keep binary support, I get 500 even though I set both 'Content-Type' and 'Accept' to 'application/json' in my client requests (done both from Postman and from cURL). I am also not sure we are supposed to send 'Content-Type' in pre-flight OPTIONS anyway, only in subsequent requests.

[brettstack]

I'll verify this later. For now, simply remove the OPTIONS method and redeploy your API and let Express deal with CORS.

[dinvlad]

With the help from staff on AWS forums, I've resolved it by adding:

x-amazon-apigateway-integration:
  contentHandling: CONVERT_TO_TEXT
  ...

which now returns a correct 200 response for the OPTIONS request. It wasn't obvious we needed to do that however, especially that this option is not available for Mock requests through the Console yet.

[samikarak]

@dinvlad

cloud you please tell us wehere to add this configuration exactly ? thanks !

[dinvlad]

@samikarak that needs to be added to the configuration of your OPTIONS methods in the Swagger template (https://github.com/awslabs/aws-serverless-express/blob/master/example/simple-proxy-api.yaml#L43)

[blackc0d3]

Hope this helps... In my case i had two functions with similar names: 'user-get-all' and 'user-get', defined in that order in the serverless.yml file. The error message i was getting was "Internal Server Error" + "Execution failed due to configuration error: Invalid permissions on lambda function. Method completed with status 500". After changing the name of the secon function to "user-get-item" it was solved. (Perhaps changing the order of the functions in the serverless.yml might work too).

Regards,

George

[individual11]

If you're not using swagger, which I wasn't, a couple things solved the issue for me. First was enabling CORS in the serverless.yml

functions:
  api:
    handler: lambda.handler
    events:
      - http:
          path: /
          method: ANY
          cors: true
      - http:
          path: /{proxy+}
          method: ANY
          cors: true

The second was making sure my Express setup allowed the OPTIONS method through:

app.use( (req, res, next) => {
   res.header("Access-Control-Allow-Origin", "*")
   res.header("Access-Control-Allow-Methods", "GET, PUT, POST, DELETE, OPTIONS")
   res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept")
   next();
 })

Hope this helps some people out. It took me a bit to figure out all the pieces.

[chriszrc]

@dinvlad Why hasn't the file you link to just been updated with the necessary fixes? Seems like this would save people a lot of headaches-
(https://github.com/awslabs/aws-serverless-express/blob/master/example/simple-proxy-api.yaml#L43)

[dinvlad]

@chriszrc I'm not in charge of this package, sorry

[chriszrc]

Lol, yes I know, sorry, maybe that didn't sound right. I was trying to ask more in general, like why hasn't this example been updated by the aws folks-

…

On Tue, May 8, 2018 at 10:14 AM, Denis Loginov ***@***.***> wrote: @chriszrc <https://github.com/chriszrc> I'm not in charge of this package, sorry — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYgWKTF928KJJCRkPk_nj0D-2mMe38G1ks5twagtgaJpZM4M7WLU> .

-- -- Chris Marx ZevRoss - Know Your Data Data Science & Spatial Analysis New website: www.zevross.com Ithaca, NY

[Jun711]

@dinvlad Do u happen to know if this can be done via API gateway console?
I only use SAM to deploy to lambda but not API Gateway.

I removed binary type * / * and OPTIONS method works using Postman. However, my audio/mp3 type doesn't work if I don't set binary type as * / *

[dinvlad]

@Jun711 haven't worked with SAM in a while, we've migrated to Firebase, sorry

[brettstack]

Reopening this to track fixing the example https://github.com/awslabs/aws-serverless-express/blob/master/example/simple-proxy-api.yaml#L43. Easy first PR for someone :)

[Jun711]

@brettstack
I noticed that even though CONVERT_TO_TEXT is specified on the template, it is not set to CONVERT_TO_TEXT on the console for OPTIONS method. I had to manually change it on the console.

[brettstack]

Okay I'll leave this open until I can confirm. Alternative is to simply remove the OPTIONS method from the Swagger template and let Lamdba handle the preflight request. Having the OPTIONS method is a performance enhancement (i.e. the response will be faster since it's terminated at the API Gateway layer)

[dinvlad]

It can also be a security mechanism, i.e. we prevent all unauthenticated access to Lambdas (in case there are any exploits that could be executed through OPTIONS in Lambda code/dependencies).

[JontyC]

Seeing the same as @Jun711 - Is the issue not that this should be also added to https://github.com/awslabs/aws-serverless-express/blob/master/examples/basic-starter/simple-proxy-api.yaml#L87

[brettstack]

@Jun711 revisiting this I realized your PR only modified the / OPTIONS and missed the /{proxy+} OPTIONS.

[Jun711]

@brettstack ok, will do. Has the folder structure been changed?

[brettstack]

Yes it's now in examples/basic-starter

[brettstack]

Thanks @Jun711. This has been merged into develop branch and we'll merge into master soon. Closing.

[Aneez-Zahra]

@brettstack would you explain this" remove the OPTIONS method and redeploy your API and let Express deal with CORS."

[gham-khaled]

With the help from staff on AWS forums, I've resolved it by adding:

x-amazon-apigateway-integration:
  contentHandling: CONVERT_TO_TEXT
  ...

which now returns a correct 200 response for the OPTIONS request. It wasn't obvious we needed to do that however, especially that this option is not available for Mock requests through the Console yet.

By adding the contentHandling I am getting the Execution failed due to configuration error: statusCode should be an integer which defined in request template .