AddAWSLambdaHosting support for application/x-www-form-urlencoded

[Simonl9l]

Describe the feature

Have bulletin support in the Lambda Hosting to transform requests of content type application/x-www-form-urlencoded into JSON structures that tie into the Minimal API [FromBody] (to define the structure) such that form data requests can be processed easily.

Use Case

Some vendors integration (Stripe specifically) use browser forms submission via once API layer to configure Checkout and Customer Portal integration, that then cause a redirect on the client.

Today this can be achieved if deploying to say and API Gateway by configuring a Request Transform for the given request; however either when running locally (debug - with Kestrel hosting) or behind and ALB this transform layer is not otherwise there so there is an impedance mismatch.

Such a feature streamlines the developer/devOps/deployment experience and minimizes extra configuration (API Gateway).

Proposed Solution

Per the feature description above this seem self explanatory.

Other Information

A potential short temp workaround would be to develop custom middle ware but its not clear (documentation) how that integrates with the Lambda runtime when not in local Kestrel mode.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS .NET SDK and/or Package version used

Amazon.Lambda.RuntimeSupport = 1.8.2
AWSSDK.ApiGatewayV2 3.7.100.54

Targeted .NET Platform

.NET 7

Operating System and version

MacOs/Windows/linux

[ashishdhingra]

Needs review with the team. Related to Lambda Annotations per #979 (comment).

[normj]

To make sure I understand is this what you have in mind

• On the call to AddAWSLambdaHosting add an option to enable x-www-form-urlencoded to JSON
• In Amazon.Lambda.AspNetCoreServer look to see if the incoming content type is x-www-form-urlencoded and perform transformation if the feature has been enabled.
  • Call HttpUtility.ParseQueryString to on the request body to turn it into a key value pair
  • Create a JSON document from the key value pair
  • Pass that new JSON into ASP.NET Core and change the content type to application/json

Is there any precedence for doing this in ASP.NET Core? I'm leery of doing this in the ASP.NET Core bridge unless there is some precedence for it. Most users that use the bridge use it because they want similar behavior local testing with Kestrel and with the deployed function. The feature might make more sense in our Lambda Annotations library we are more designing our own programming model.

[Simonl9l]

@normj thanks for jumping on the thread!

You final comments make a good point - per precedence.

We have had significant trouble using the developer/testing tools (aws/aws-toolkit-jetbrains#3175) with the Annotations Lambdas and as such have limited our usage - opting for the ASP.NET Core bridge approach - so your Kestrel "similar behavior" point runs true.

The gap this is trying to close its that there a numerous articles that show to do the transform in the API Gateway, and this is not available the running local via Kestrel - largely to provide a work around for limited [FromForm] semantics in Aps.Net Core (dotnet/aspnetcore#39430). I think I saw something to do with Annotation here too?

So yes this was pitched incorrectly as the need for more a developer support feature. As such perhaps this is better suited to the testing tools and the ability to have that perform transforms ones API Gateway would otherwise?

Per the issue above (aws/aws-toolkit-jetbrains#3175) since it seems to be an AWS repo (?) I wonder of you have any influence there?

On review we can drop/close this feature Request!

Whilst also talking annotations, the only other challenge we see short term with a wider adoption vs. the Kestrel bridge, beyond developer tooling, is related to:

1. [FromForm] Semantics
2. With CDK (C#) each lambda endpoint is effectively a separate Artifact and Deployment, as the Hander is specific to each Function. We can't it seems hook multiple Handlers up to the same deployed Artifact.
3. Bring your own DI (code generated)

Also AoT support as discussed elsewhere - ties to #2 - but also the broader AWSSDK and its use of reflection (Try semantics) and ensuring Trimming primitives are set up correctly - We have to do Self Contained/Single Executable builds as we run into Lambda size limitation quickly. This invariably needs trimming too.

[normj]

@Simonl9l I responded to your issue for debugging Annotations with Rider. I would like to understand more your comments about the Annotations library in general. If you are up for video call I would love to get together and discuss it. You can email me if you that sounds interesting. My email is the same username normj with the @amazon.com domain added to it.

[normj]

I am going to close the issue in the context of ASP.NET Core though.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.