set Content-Length header in mapApiGatewayEventToHttpRequest

[HotelCalifornia]

Issue #, if available:
#106
Description of changes:

• without content-length specified, it seems the body of DELETE requests get ignored
• per RFC 2616, section 4.3:

  The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

  • in other words, whether or not it is recommended to have a body in a DELETE request, if the content-length header (or the transfer-encoding header) is set, the message body should be forwarded
• concerns:
  • I'm not sure whether it is necessary to perform more type checking on event.body. for instance, if it is an object, it should be passed through a call to JSON.stringify before getting the byte length not necessary
  • the header should probably be set only if not already specified 1ef34b8

I would love feedback on this 🙇

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[HotelCalifornia]

I recognize now that this may be the same change as in #130, though I can now confirm that this issue is also the cause of #106

[brettstack]

"if it is an object, it should be passed through a call to JSON.stringify before getting the byte length" - event.body will always be a string, so no concern here.

Could you fix the failing tests and I'll get this merged in soon.

[brettstack]

Could you also add a comment: // NOTE: API Gateway is not setting content-length header on DELETE requests even when they have a body

[HotelCalifornia]

Yeah, I can get those addressed tomorrow

[HotelCalifornia]

note that by the section of RFC 2616 I quoted above, the bit about content-length applies to other normally bodiless requests, like GET (i.e. if the request has a body, content-length should be set, regardless of whether it is good practice). I bring this up because the failing test cases send a GET request with a body:

https://github.com/awslabs/aws-serverless-express/blob/42a5501f2ef393461e6d53c4ab28ab343d83044b/__tests__/index.js#L46-L62

the header is not set when the dummy event is cloned since my changes add the content-length inside this call

https://github.com/awslabs/aws-serverless-express/blob/42a5501f2ef393461e6d53c4ab28ab343d83044b/__tests__/index.js#L59

which means failure at the later call

https://github.com/awslabs/aws-serverless-express/blob/42a5501f2ef393461e6d53c4ab28ab343d83044b/__tests__/index.js#L86

I'm not really sure what the best way to go about remedying this would be. Maybe something like

            'x-apigateway-event': encodeURIComponent(JSON.stringify({
                'Content-Length': Buffer.byteLength('Hello serverless'),
                ...r.eventClone
            })),

(or the [functionally] equivalent Object.assign call)

[brettstack]

Okay. Your PR is method-agnostic so should work for GET also. Maybe make the comment a little more generic

[brettstack]

I don't think this is true. It correctly sets it for POST and PUT, right? Otherwise we'd be seeing this error on every method. Confirmed methods where it doesn't appear are GET and DELETE and I wouldn't be surprised if OPTIONS also didn't have the header.

[brettstack]

Could you remove this address whitespace?

[HotelCalifornia]

re: does it correctly set for POST/PUT?

@ajstocchetti set up a little test for this. running the following lambda as an API gateway integration:

const awsServerlessExpress = require('aws-serverless-express');
const app = require('./app');
const server = awsServerlessExpress.createServer(app);

exports.handler = (event, context) => {
    const headers = event.headers;
    const len = headers && headers['Content-Length'] ? headers['Content-Length'] : null;
    const cl = {
        method: event.httpMethod,
        headers,
        contentlength: len,
        body: !!event.body,
    };
    console.log(cl);
    return awsServerlessExpress.proxy(server, event, context);
}

produces the following output in cloudwatch:

2018-06-21T20:14:39.195Z	b94aa582-758f-11e8-8c38-4dde4dcb5d6c	{ method: 'POST',
headers: 
{ Accept: '*/*',
'accept-encoding': 'gzip, deflate',
'cache-control': 'no-cache',
'Content-Type': 'application/json',
Host: 'xxxxxxxxxx.execute-api.us-east-1.amazonaws.com',
'Postman-Token': '6293826b-1004-403c-a954-9b4da0747930',
'User-Agent': 'PostmanRuntime/7.1.5',
'X-Amzn-Trace-Id': 'Root=1-5b2c072e-375932d0e0bc47d2658c8028',
'X-Forwarded-For': 'XX.XX.XX.XX',
'X-Forwarded-Port': '443',
'X-Forwarded-Proto': 'https' },
contentlength: null,
body: true }

[HotelCalifornia]

also, I'm not sure why that last test is failing, but I don't think it has to do specifically with the changes I've made...

[brettstack]

It's failing in latest version of Node due to Buffer deprecation. I'll remove it from Travis config.

I'll open a ticket internally to investigate the content-length header not being sent.

Thanks! I'll have my integ tests out for PR soon. I'll merge this in immediately after that gets merged in.

[brettstack]

Could you rebase? The travis config has changed to support the new tests. You may also need to fix some tests. Alternatively if you want to push this to develop branch I can merge and fix from there.

[HotelCalifornia]

@brettstack I've changed the base branch to develop

[brettstack]

I've implemented this in a separate branch with some changes. The integ tests are already paying off as they found an issue with doing this with base64Encoded requests. Thanks for all your help and patience.