-
Notifications
You must be signed in to change notification settings - Fork 10
Description
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!