Hi @vincentsarago! I ran into a pretty weird quirk when attempting to put a proxy Lambda endpoint behind a custom domain with base path mapping. I thought it might be useful to add a workaround fix to this repo. Let me explain...

For example, I have:

• An API Gateway with a nasty URL abcdef123456.execute-api.us-east-1.amazonaws.com
• A {proxy+} Lambda resolver (it's a tile server 😄)
• An API Gateway custom domain foo.danschoppe.com
• A base path mapping in the custom domain to point /tiler -> deployed Lambda stage

With this setup, one would expect a request to abcdef123456.execute-api.us-east-1.amazonaws.com/bar to behave identically to a request to foo.danschoppe.com/tiler/bar. Unfortunately, as described in CodeGenieApp/serverless-express#216, the value of event.path for the custom domain erroneously includes the 'tiler/' prefix from the base path mapping. So in first request the value of event.path is 'bar', and in the second request the value of event.path is 'tiler/bar'.

This looks to be a quirk of API Gateway where the event.path includes the base path mapping of a custom domain. As you can imagine, this breaks the routing of a project like lambda-proxy.

As folks in the aforementioned issue realized, event.pathParameters.proxy is a more reliable source of route information than event.path for this scenario. In the examples above, both requests result in a event.pathParameters.proxy value of 'bar'.

What are your thoughts on adding support to optionally use event.pathParameters.proxy for route matching? The option could be configured via environment variable, such that it can be determined at deploy time.

Thanks for your thoughts!