DianaIonita / serverless-api-gateway-caching

A plugin for the Serverless framework which helps with configuring caching for API Gateway endpoints.
ISC License
136 stars 34 forks source link

Upgrade from 1.7.5 to 1.8.0 breaking API Gateway endpoint #109

Closed smingins closed 2 years ago

smingins commented 2 years ago

Hi

The changes here https://github.com/DianaIonita/serverless-api-gateway-caching/pull/107 are setting these request parameters and breaking the API endpoint that has them applied. The Cloudformation template now has:

"RequestParameters":
  {
    "integration.request.header.Origin": "method.request.header.Origin",
    "integration.request.header.origin": "method.request.header.origin",
  },

When before it was:

"RequestParameters": {}

The serverless.yml entry looks like:

  health:
    handler: src/api/v1/health.handler
    events:
      - http:
          path: v1/health
          method: get
          cors: true
          caching:
            enabled: true
            cacheKeyParameters:
              - name: request.header.Origin
              - name: request.header.origin

Is there something that I can do to fix this?

DianaIonita commented 2 years ago

Hi @smingins, Thanks for raising this issue. Please use v1.7.5 while I look into how best to sort it.

DianaIonita commented 2 years ago

Hi @smingins,

I tried replicating the issue you mention, but my deployment works fine and I can see in the AWS Console both the Origin and origin headers properly configured as cache key parameters. Would you mind sharing the error you're getting and the version of the serverless framework you're using, please?

smingins commented 2 years ago

Hi @DianaIonita

The issue is the setting of the RequestParameters and it is causing a 500 error at the API gateway.

And when we revert to 1.7.5 those are empty (as above) and all is well :-)

We are using Serverless framework 3.16.0

I will try and find some time to switch back to 1.8.0 and see if we can get some more info.

smingins commented 2 years ago

Hi @DianaIonita

The issue is where the Integration Request Parameters are now being set to the Cache Key Parameters.

I did find if I only set one like:

- name: request.header.origin

It's fine, but as the header could come through as Origin we are setting both (as per original issue above).

The lambda is not being executed and the API gateway logs show:

Lambda invocation failed with status: 403

What happened when you call your endpoint with the Origin header set?

What are the Integration Request Parameters being set for now?

DianaIonita commented 2 years ago

Hi @smingins,

Thanks for the details, I am able to reproduce the error you're seeing. It looks like it has something to do with both the origin and Origin headers set as cache key parameters, and it also happens if I configure other headers with different casing. I'll work on a fix and let you know.

DianaIonita commented 2 years ago

Hi @smingins,

I just released v.1.8.1 which should hopefully fix your problem. Please reopen the issue if that's not the case.