Cannot pass body with event.json about serverless-http HOT 9 CLOSED

Found the problem: in the original example @centosGit is passing application-json instead of application/json.

In my case I was being obtuse and not passing Content-type at all.

I tested this in 1.5.2 and used bodyParser. Thanks so much for the help @dougmoscrop , alas there was no bug here!

from serverless-http.

It's a problem with escaping so the parser doesn't pre-parse the body.

example (not sure if it's the correct way)

{
        "path": "/upload",
        "httpMethod": "POST",
        "headers": {
                "Content-Type": "application-json"
        },
        "queryStringParameters": null,
        "pathParameters": null,
        "stageVariables": null,
        "body": "{\\\"image\\\":\\\"asdf\\\"}",
        "isBase64Encoded": false
  }

from serverless-http.

Tried your approach and still doesn't work. Don't know if this is a serverless issue or from this package.

from serverless-http.

It's an issue in the sense that I specifically wrote code to reject a pre-parsed body because it's a sign that something changed in how Lambda is calling the function; it should be a string, so it can be parsed

I could probably make this work by doing

body = JSON.stringify(body)

instead of throwing an exception.

from serverless-http.

I ran into this same problem and couldn't figure out the best way to handle it. My problem is I'm not entirely sure of the structure that comes out of API Gateway and gets passed to Lambda, so invoking the function locally doesn't do what I expect. I was referred to serverless-offline, which emulates the API Gateway layer on your localhost. Then you don't have to worry about how the data gets between APIG and lambda, you can just test on both ends of pipeline for correctness.

from serverless-http.

If serverless-offline calls your function with an object as the event body, it has a bug. That's not what API gateway will do as far as I understand.

If APIg does sometimes call your lambda with an object as the body, I'd like to see an example of what that looks like. You don't need to use serverless-http to capture that, just

module.exports.handler = function(event, context, callback) {
  console.log(JSON.stringify(event))
  callback();
};

from serverless-http.

I did the logging you suggested in my deployment and here's what's coming back (identifying details omitted ofc):

{
    "resource": "/path",
    "path": "/path",
    "httpMethod": "POST",
    "headers": {
        "Accept": "application/json,*/*",
        "Accept-Encoding": "gzip,deflate",
        "CloudFront-Forwarded-Proto": "https",
        "CloudFront-Is-Desktop-Viewer": "true",
        "CloudFront-Is-Mobile-Viewer": "false",
        "CloudFront-Is-SmartTV-Viewer": "false",
        "CloudFront-Is-Tablet-Viewer": "false",
        "CloudFront-Viewer-Country": "US",
        "Content-Type": "application/x-www-form-urlencoded",
        "Host": "host.execute-api.us-east-1.amazonaws.com",
        "User-Agent": "Slackbot 1.0 (+https://api.slack.com/robots)",
        "Via": "1.1 host.cloudfront.net (CloudFront)",
        "X-Amz-Cf-Id": "cf-id",
        "X-Amzn-Trace-Id": "Root=trace-id",
        "X-Forwarded-For": "ip-address",
        "X-Forwarded-Port": "443",
        "X-Forwarded-Proto": "https"
    },
    "queryStringParameters": null,
    "pathParameters": null,
    "stageVariables": null,
    "requestContext": {
        "requestTime": "20/Jan/2018:20:41:29 +0000",
        "path": "/path",
        "accountId": "accountId",
        "protocol": "HTTP/1.1",
        "resourceId": "resourceId",
        "stage": "dev",
        "requestTimeEpoch": 1516480889081,
        "requestId": "requestId",
        "identity": {
            "cognitoIdentityPoolId": null,
            "accountId": null,
            "cognitoIdentityId": null,
            "caller": null,
            "sourceIp": "52.54.222.230",
            "accessKey": null,
            "cognitoAuthenticationType": null,
            "cognitoAuthenticationProvider": null,
            "userArn": null,
            "userAgent": "Slackbot 1.0 (+https://api.slack.com/robots)",
            "user": null
        },
        "resourcePath": "/path",
        "httpMethod": "POST",
        "apiId": "apiId"
    },
    "body": "token=token&team_id=team_id&team_domain=team_domain&channel_id=channel_id&channel_name=channel_name&user_id=user_id&user_name=user_name&command=%2Fcommand&text=&response_url=https%3A%2F%2Fhooks.slack.com%2Fcommands&trigger_id=trigger_id",
    "isBase64Encoded": false
}

Putting this into event.json and invoking the function still logs body as undefined.

from serverless-http.

Cool thanks for checking in to it!

There's a lot of things at play here. I think the event looks normal. What does your actual app/http handler handler look like? I know it seems counter-intuitive because the event body is "right there" but this library exists specifically to "hide" Lambda from your application code as much as possible, so you need something to parse that body - just like you would if you were in a regular Node.js application listening on a port. So if you're using express, you'd want to app.use(bodyParser.urlencoded());

If that still presents an empty body, could be a bug - but I do have tests for bodyParser (https://github.com/dougmoscrop/serverless-http/blob/master/test/express.js#L33) just not urlencoded specifically.

from serverless-http.

OK, I published 1.5.3 that will support passing a body in as an object if the content-type is JSON.

I really think this is a sign of something else misconfigured, i.e. the local invoke or offline plugin is doing parsing when it should not... but this might let you use them for now.

You still need to configure body parsing like I mentioned, because this library is going to turn it in to a string and send it through as part of the req stream. I'm also curious what these offline or local invokes do in terms of setting content-type and content-length headers...

Let me know if this helped or changed the errors you are getting.

from serverless-http.