Skip to content

Request URI is wrong when using API Gateway in some common cases #107

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

Closed
iliana opened this issue May 27, 2019 · 8 comments · Fixed by #426
Closed

Request URI is wrong when using API Gateway in some common cases #107

iliana opened this issue May 27, 2019 · 8 comments · Fixed by #426
Assignees
Labels
bug Something isn't working

Comments

@iliana
Copy link

iliana commented May 27, 2019

Without using a custom domain mapping in API Gateway, the URI looks like:

https://1234567890.execute-api.us-east-1.amazonaws.com/prod/a/b/c

where prod is the deployment stage. Currently lambda_http doesn't include the stage in the URL (but it looks like it's available in the event).

I tested it and it works fine with an empty custom domain mapping, but a non-empty custom domain mapping might also not work; I didn't test that, and I'm not sure if the domain mapping is present in the event.

(I'm running into this because I'm writing request validation for a Twilio endpoint, which involves concatenating key/value pairs onto the URL Twilio knows. So I'm relying on Request::uri().to_string().)

@bernardobelchior
Copy link

This is due to this portion of code:

let mut builder = HttpRequest::builder();
        builder.method(http_method);
        builder.uri({
            format!(
                "{}://{}{}",
                headers
                    .get("X-Forwarded-Proto")
                    .map(|val| val.to_str().unwrap_or_else(|_| "https"))
                    .unwrap_or_else(|| "https"),
                headers
                    .get(HOST)
                    .map(|val| val.to_str().unwrap_or_default())
                    .unwrap_or_default(),
                path
            )
        });

You can see that not only are stage variables not available, but the query string is also being ignored.
I have run into the same problems, as I am using Uri::parse to obtain values from the query string.

@saks
Copy link
Contributor

saks commented Jun 6, 2019

Hey @bernardobelchior! I'm not 100% sure that this exactly what you need, but I'd suggest to take a look at RequestExt trait. It provides few methods for accessing url and path params.

@bernardobelchior
Copy link

Thanks, @saks! That was the solution!
Nevertheless, this still seems like a bug

@softprops
Copy link
Contributor

I can take a closer look at this

@GREsau
Copy link

GREsau commented Aug 21, 2019

I'm having a similar issue with the stage missing from the path, which breaks absolute paths from the webserver e.g. in the Location header of 302 responses.

I'm able to arbitrarily modify the incoming request, so I could just get the stage from the request context and prepend it to the path - but I think that would then break custom domain mappings, as they don't include the stage in the path.

I assume the most reliable way of getting the original "real" path (i.e. what the end-user would have in their browser's address bar) would be to use the request context's path property, but that's not included in the RequestContext::ApiGateway struct - in fact, it's explicitly commented out, any idea why?

@maxcountryman
Copy link

I assume the most reliable way of getting the original "real" path (i.e. what the end-user would have in their browser's address bar) would be to use the request context's path property, but that's not included in the RequestContext::ApiGateway struct - in fact, it's explicitly commented out, any idea why?

I'm also curious about this--when I first encountered this issue my instinct was to use the path, but unfortunately it's not available, as you point out.

@jkshtj jkshtj added the bug Something isn't working label Jan 21, 2021
@duaneking
Copy link

duaneking commented Sep 5, 2021

There is no legitimate reason for this path not to be included and correct.

@duaneking
Copy link

duaneking commented Sep 5, 2021

@softprops May I ask the status of this? I normally don't like pinging people directly but you stated above you were working on this.. and this is core to the typical usage of rust and lambda.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants