Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path resolution for API Gateway custom domain base path mapping #16

Closed
DanSchoppe opened this issue Jul 30, 2019 · 7 comments · Fixed by #17
Closed

Path resolution for API Gateway custom domain base path mapping #16

DanSchoppe opened this issue Jul 30, 2019 · 7 comments · Fixed by #17

Comments

@DanSchoppe
Copy link

DanSchoppe commented Jul 30, 2019

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!

@vincentsarago
Copy link
Owner

hey thanks for this great issue @DanSchoppe
I've encountered this couple time but did not go to the end of it, so really Thanks.

Using event.pathParameters.proxy seems to make more senses for this library. I guess maybe here

resource_path = event.get("path", None)

we could do something like

if event.get("pathParameters"):
    resource_path = event["pathParameters"].get("proxy", None)
else:
    resource_path = event.get("pathParameters", None)

This would need to be tested

@DanSchoppe
Copy link
Author

Yes, I'm on board with statically using event.pathParameters.proxy.

Is it possible in API Gateway to configure a wildcard variable name different than proxy? That's certainly the convention I stick to, just wondering whether you'd like to try to support others.

I'd be happy to PR this change if you'd like. It could even be a one-liner, falling back to event.path if event.pathParameters.proxy didn't exist:

event.get('pathParameters', {}).get('proxy', event.get('path'))

@vincentsarago
Copy link
Owner

I'll open the PR and start testing

@vincentsarago
Copy link
Owner

vincentsarago commented Jul 31, 2019

Is it possible in API Gateway to configure a wildcard variable name different than proxy?

I don't think so but that could be a problem if it does

@vincentsarago
Copy link
Owner

well I lied https://t6h72rcprc.execute-api.eu-central-1.amazonaws.com/production/{hey+}

you can put whatever you want. Not sure what we should do about it, make it configurable or just mention that we force {proyx+} which is the default everywhere. cc @DanSchoppe

@DanSchoppe
Copy link
Author

DanSchoppe commented Jul 31, 2019

Thanks for testing this! A couple thoughts:

  • We could probably stick with proxy because that's very likely what people will be using
  • If we want to support other variable names, we could allow the user to override proxy with a custom variable name via environment variable. Honestly though, this seems like unnecessary complexity

Regarding your PR comment #17 (comment)

The only problem is that when adding a mapping path, the / route wont work because the app will try to look for /tiler/ route instead of / but I guess this is the kind of thing we need to just document.

I guess I don't fully understand. Is this because there is no event.pathParameters.proxy value for root mapping, and the app is falling back to using event.path? I was under the impression that even base path mappings of / would have a valid pathParameters.proxy value.

@vincentsarago
Copy link
Owner

We could probably stick with proxy because that's very likely what people will be using

I found a solution to support any variable. The {proxy+} is set in event.resource so it's easy to extract proxy or any name.

I guess I don't fully understand. Is this because there is no event.pathParameters.proxy value for root mapping, and the app is falling back to using event.path?

Yes

I was under the impression that even base path mappings of / would have a valid pathParameters.proxy value

No they don't because they are not considered as {proxy+}. I'll show how to overrule this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants