Aws-lambda-dotnet: Best way to use a Lambda from API-GW with Custom Domain Name?

[Kralizek]

Hi,
I'm experiencing some issues with API Gateway and how it interacts with a Custom Domain Name.

In the attached file, there is a Lambda function based on the API Gateway Proxy base class.
It simply returns the requested path: app.Use(async (context, next) => { await context.Response.WriteAsync(context.Request.Path); });

Everything works as it should

• when I test the function locally,
• when I test the function on the Lambda console
• when I test the function through the API Gateway stage URL

It stops working when I start using the Custom Domain Name.
The CDN is simply created with a base path mapping "test" -> "apigw-test:Production"

In my test I see that if I request https://api.mydomain.net/test/foo/bar where test is the base path mapping and foo/bar is the actual path that should be passed to the Lambda, the Lambda receives the whole /test/foo/bar. This obviously causes the ASP.NET routing engine to fail to bind the request to a Controller/Action (in the attached example I skipped the ASP.NET MVC part, but it's pretty easy to test)

I'm not sure it's a bug, but I wonder if you have a workaround to be used, at least on production.

Thanks

TestLambda.zip

[normj]

I'm curious what the the request coming in from API Gateway looks like. Could you add the environment variable LAMBDA_NET_SERIALIZER_DEBUG with a value of true.

Once you do that execute the function again from the custom domain. After you do that check the CloudWatch logs to find the original JSON request. Could you add that JSON document to the issue?

The LAMBDA_NET_SERIALIZER_DEBUG environment variable does require version 0.10.1-preview1 of Amazon.Lambda.AspNetCoreServer.

[Kralizek]

Here are the logs for the three requests I did:

1) test event from the Lambda console 01 - lambda console test event.txt
2) via API stage ( https://6bgh10txr3.execute-api.eu-west-1.amazonaws.com/Production/foo/bar ) 02 - api gw - stage.txt
3) via Custom Domain Name ( https://api.emg-services.net/test/foo/bar ) 03 - api gw - cdn.txt

[normj]

Thanks for the logs. Our code is currently using the $.path field for the resource path and I see it should be using $.pathParameters.proxy. I'll make that change and get that released.

[Kralizek]

Great! thanks for your help! :D

[normj]

I have the fix complete. I'm trying to finish off another fix which I'm currently waiting feedback on and then ship both fixes. If this is critical and can't wait a day or so let me know and I'll ship this fix separately.

[Kralizek]

Definitely no rush on my side. We're temporarily running the same Web app hosted on IIS.

[Kralizek]

Hi @normj is there any update?

[normj]

I just released version 0.10.2 that has this fix.

[normj]

Closing I believe this is solved. Feel free to reopen if there are more questions/issues.

[Kralizek]

Hi @normj, sorry for not getting back to you. Preliminary testing confirms that the fix is working as expected. I will get back to you when my developer on the issue will find time to thoroughly test it.

[ddrinka]

@normj I feel like https://github.com/aws/aws-lambda-dotnet/commit/0a3fb00cfb6f09d14618e7ff2544ce0478c9b7b0 reverts this change.

My expectation for the path provided to ASP.Net Core is that it be the contents of {proxy+}, i.e. PathParameters["proxy"]. The resources before that point may change, but the handler should always handle the proxied portion of the URL.

In the fix for this issue, it appears that's what the code did. If PathParameters["proxy"] exists, use it as the path. If not, use Path.

In the above linked commit, you flipped that back to replacing {proxy+} in the Resource with the PathParameters["proxy"]. This seems to revert back to sending the full path, including preceding resources.

I'd like to be able to provide an option to builder.UseApiGateway that specifies if the entire path through the API Gateway resources are included in the path, or only the Proxy+ portion.

[ddrinka]

For anyone wishing for the behavior I described above, here's a bit of middleware to utilize the proxy path rather than the full path for routing. Include this before app.UseMvc().
https://gist.github.com/ddrinka/8418fef0fcc6f9455dd2c01f645560c6

[normj]

@ddrinka Could you open a new issue for this? Comments on old closed post tend to get lost.

[ddrinka]

Thanks @normj . Don't let this distract you from getting Core 2.0 support out! It's getting really hard to build for 1.0 these days. :)

[normj]

I'm going through this code now for the upcoming .NET Core 2.0 release so it is a good time to look into the issue. Any changes would be rolled into the upcoming 2.0 release.