Using proxy+ API Gateway configuration with 2.0 payload?
See original GitHub issueI’ve configured a new AWS API Gateway (HTTP) endpoint mapping a route of /{proxy+}
to an AWS Lambda .NET Core WebAPI application with multiple endpoints defined internally for WebAPI.
It was failing with a 500 error after setting it up. Cloudwatch logs showed:
Object reference not set to an instance of an object.: NullReferenceException
at Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction.MarshallRequest(InvokeFeatures features, APIGatewayProxyRequest apiGatewayRequest, ILambdaContext lambdaContext)
at Amazon.Lambda.AspNetCoreServer.AbstractAspNetCoreFunction`2.FunctionHandlerAsync(TREQUEST request, ILambdaContext lambdaContext)
at lambda_method(Closure , Stream , Stream , LambdaContextInternal )
I assumed the problem was with in some other part of my configuration (since most of the example code I found for setting this up assumed .NET Core 2.x instead of my 3.x), and so it took me a while to realize that if I go into the Advanced Settings of the route definition, and changed the payload format from the default 2.0 format to the 1.0 format, it would work fine.

Is there a reason Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction
requires the 1.0 payload? Is that optimal/desired?
Also, is there an official AWS documentation of the .NET WebAPI technique using the special /{proxy+}
route definition? I actually only realized this setup was possible when I stumbled upon a third party explanation of mapping a single API Gateway route to multiple endpoints in WebAPI. So far have not been able to find official documentation of how it works, etc.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:15 (7 by maintainers)
When you want to use HTTP API with 2.0 payload you need to change the base class from
APIGatewayProxyFunction
toAPIGatewayHttpApiV2ProxyFunction
. I have a blog post coming out on that covers this very soon.I was able to get web sockets working using the standard proxy.
The primary trick was settings all this info at the top before calling the parent marshal method.
Once I mocked all that I was successfully able to handle a websocket request like a standard rest api request.
The other piece was than mapping the route keys and event types to their respective rest / http equivalents. That is what is being done PostMarshallRequestFeature.
I’m explicitly mapping all this here. However, I’m sure this could be done in an automated fashion by mapping the body of the request to an event and using the event info to route dynamically based on custom attributes on a class and methods. That would probably be the most ideal solution. However, this seems to work well. It also provides me with the ability to use the lambda in both api gateway and api gateway web socket as a sort of hybrid.
Here is an example of the controller.
You can basically treat the web socket api the same as a rest api as long as you define the proper mappings. Like I said it would be cool if this where integrated somehow to be dynamic based on attributes. However, as a simple working example what I did seems to function.
This bit here is for authenticating since client side does not allow headers to be set the token must be passed in the query string. However, its easy enough to intercept the request and put the token where the jwt verification process expects it in the hdeaders.
However, that token is only going to be present in the connect. So you need to save the connection and token association somewhere in persistent storage to map the connection id to the user / token in methods / actions called after connecting. I haven’t gotten that far yet. I was going to use cassandra but am having other problems related to that piece.