Cannot read property 'Access-Control-Request-Headers' of undefined Apollo-Server-Lambda

[JacobT14]

I am currently using Apollo-Server-Lambda 2.0.4

My lambda logs are showing a lot of instances of this error:

TypeError: Cannot read property 'Access-Control-Request-Headers' of undefined
at /var/task/node_modules/apollo-server-lambda/dist/ApolloServer.js:63:38

However, it looks like the request is still responding just fine to the client, so it isn't really breaking anything, but my lambdas are technically erroring out. I'm not really sure in what scenarios it is happening, but I'm thinking that it is the cors preflight check, as it happens before a lot of requests.

[JacobT14]

Have confirmed that this is happening when an options request is sent to the API Endpoint, but I'm not really sure why event.headers is undefined in that case?

[charleswong28]

Check this comment.

---

Faced the same problem using 2.0.4. Tried to downgrade to 2.0.3 but it won't work because of the apollo-upload-server issue #1542.

Here is the log for event and context without cors params to createHandler(). event.headers is missing. Only request payload is present.

START RequestId: Version: $LATEST
2018-08-24T09:11:10.112Z event: { operationName: null,
  variables: {},
  query: '{
  me {
    sub
  }
}
' }
END RequestId: ---
REPORT RequestId: --	Duration: 105.37 ms	Billed Duration: 200 ms 	Memory Size: 1024 MB	Max Memory Used: 98 MB	

And running using serverless offline. event.headers is present.

event: { headers: 
   { Host: 'localhost:4000',
     Connection: 'keep-alive',
     'Content-Length': '76',
     accept: '*/*',
     Origin: 'http://localhost:4000',
     authorization: 'Bearer ---',
     'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36',
     'content-type': 'application/json',
     Referer: 'http://localhost:4000/playground',
     'Accept-Encoding': 'gzip, deflate, br',
     'Accept-Language': 'en-GB,en-US;q=0.9,en;q=0.8' },
...
 }

[charleswong28]

My observation was wrong in the above comment.

The problem is because of the setting in API gateway. When you are using integration setting other than Lambda Proxy Integration or integration: LAMBDA-PROXY in serverless, the event object is not constructed as what apollo-server expects. event.headers doesn't exists so you will see Cannot read property 'Access-Control-Request-Headers' of undefined.

Also, the event object is constructed according to your setting in integration setting. When you test your lambda function in aws console without any parameters, you will also see this error since the request is not properly constructed through API gateway. (This is why I only got payload in the above comment.)

You may find this helpful.

You can also confirm it by checking this.

const graphqlHandler = (event, context, callback) => {
  console.log('event in handler', event);
  server.createHandler({
    cors: {
      origin: '*',
      credentials: true,
    },
  })(event, context, callback);
};

In my case, event.headers is already undefined since my API Gateway setting is not correct.

---

If you are using multipart/form-data, it works using Lambda Proxy Integration and adding multipart/form-data to Binary Media Types (Check this for details). You will then see event.isBase64Encoded to be true. You can parse the event body using Buffer.from(event.body, event.isBase64Encoded ? 'base64' : 'ascii').

If you are using serverless, you will find it working on serverless-offline by just using ascii as encoding but when you deploy to API Gateway, the stream will be encoding wrongly.

[aarkerio]

if you are testing in the AWS lambda console, you need to create a new test event json like:

{ "headers": {"origin":true} }

[caydie-tran]

Thanks for reporting this issue originally!

I'm going to close this issue since it hasn't received a lot of traction and could have been resolved already.

If this is still a problem, would someone who's experiencing the problem (or anyone who comes across this issue and is able to assist) mind building a reproduction of the problem in to a runnable CodeSandbox reproduction using the latest version of Apollo Server and sharing the link to that CodeSandbox in this issue?

I'm happy to re-open if this is still occurring and someone can provide a reproduction. Thanks again!