API Gateway Path Mapping Problem

[feinstein]

• Framework version: 0.9
• Implementations: Jersey (but I believe this affects all versions)

Scenario

All the details of this issue can be found on this AWS Forums thread.

Basically, regular URLs and Custom Domain Name URLs From API Gateway, inconsistently map their URL paths to the invoked a Lambda Function.

Here's my invocation logs, from bot a regular API Gateway URL and a Custom Domain Name URL:

Custom Domain Name URL:

"resource":"/{proxy+}","path":"/service/prod/test", 
"Host":"api.myservice.com", 
"pathParameters":{"proxy":"test"}
"path":"/service/prod/test",
"stage":"prod",

Regular URL:

"resource":"/{proxy+}","path":"/test", 
"Host":"aaaaaaaaaaa.execute-api.us-east-1.amazonaws.com", 
"pathParameters":{"proxy":"test"},
"path":"/prod/test",
"stage":"prod",

The same Lambda Function, invoked with both URLs will produce different resutls, since the path being passed is different, the Lambda Function invoked with:

https://aaaaaaaaaaa.execute-api.us-east-1.amazonaws.com/prod/test

will execute normaly, but the same Lambda Function invoked with:

https://api.myservice.com/service/prod/test

will return 404 since the path being passed to Jersey by this framework will be an invalid one.

Expected behavior

Calling both APIs will invoke the Lambda Function consistently with the same path and both will execute on the same way.

Actual behavior

https://aaaaaaaaaaa.execute-api.us-east-1.amazonaws.com/prod/test

will execute normaly, but the same Lambda Function invoked with:

https://api.myservice.com/service/prod/test

will return 404 since the path being passed to Jersey by this framework will be an invalid one.

Steps to reproduce

1 - Create a new API Gateway {proxy+} method that invokes a Lambda Function running Jersey
2 - Create a Custom Domain Name and a basepath mapping for that Lambda Function
3 - Invoke the API using both URLs

---

From the logs:

Custom Domain Name URL:

"resource":"/{proxy+}","path":"/service/prod/test", 
"Host":"api.myservice.com", 
"pathParameters":{"proxy":"test"}
"path":"/service/prod/test",
"stage":"prod",

Regular URL:

"resource":"/{proxy+}","path":"/test", 
"Host":"aaaaaaaaaaa.execute-api.us-east-1.amazonaws.com", 
"pathParameters":{"proxy":"test"},
"path":"/prod/test",
"stage":"prod",

I can see the pathParameters are the same on both cases, but the path is different.

Is this library using the path and this is the source of the problem? Could it change to using the pathParameters instead?

[sapessi]

Hey @feinstein, you can use the stripBasePath option of the ContainerConfig object. We have a shorthand syntax in the handler to set this:

handler.setStripBasePath("/service/prod");

Alternatively, you can grab the current config and modify it handler.getContainerConfig()

I'll add this to the docs.

[feinstein]

Oh, interesting, I will take a look at this, thanks!

[feinstein]

@sapessi I can't find the setStripBasePath or the getContainerConfig on the JerseyLambdaContainerHandler, is this the handler you are referring to?

My StreamLambdaHandler is almost a direct copy from the docs and the JerseyLambdaContainerHandler is the only handler I can see.

[sapessi]

Yeah, I can find it in the sample. My handler would change like this:

public class StreamLambdaHandler implements RequestStreamHandler {
    private final ResourceConfig jerseyApplication = new ResourceConfig()
                                                             .packages("com.amazonaws.serverless.sample.jersey")
                                                             .register(JacksonFeature.class);
    private final JerseyLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> handler
            = JerseyLambdaContainerHandler.getAwsProxyHandler(jerseyApplication);

    public StreamLambdaHandler() {
        // we enable the timer for debugging. This SHOULD NOT be enabled in production.
        Timer.enable();
    }

    @Override
    public void handleRequest(InputStream inputStream, OutputStream outputStream, Context context)
            throws IOException {
        handler.stripBasePath("/service/prod");
        AwsProxyRequest request = LambdaContainerHandler.getObjectMapper().readValue(inputStream, AwsProxyRequest.class);

        AwsProxyResponse resp = handler.proxy(request, context);

        LambdaContainerHandler.getObjectMapper().writeValue(outputStream, resp);

        System.err.println(LambdaContainerHandler.getObjectMapper().writeValueAsString(Timer.getTimers()));

        // just in case it wasn't closed by the mapper
        outputStream.close();
    }
}

[feinstein]

I am sorry, my bad, it's late in here, I made a typo and auto-complete wasn't working, ops!

[feinstein]

@sapessi now I am getting 404 on both URLs.

I will try to see the path being passed logging request.getPath().

Are there any caveats on using the pathParameters instead of the path passed to the Lambda Function?

[sapessi]

For routing, pathParameters only works if you have API Gateway configured with a {proxy+} catch-all path. If you specify the specific resource, for example /orders/{id}, I would only get the id value in the pathParameters object.

I'm looking into the path.

[feinstein]

I see, it makes sense.

[feinstein]

@sapessi where is the code that actually strips the base path? I want to double check it's logic to see the final path, so I cant figure out why both URLs now return 404.

[sapessi]

The path is stripped by the request reader. Here's the call to it and here's the method implementation

[feinstein]

Thanks! I will try to figure out what is going on here....

[sapessi]

thanks. Ping here if you think there's something wrong