Repository: awslabs/aws-lambda-rust-runtime (language: rust)

Issue:
Axum cannot route properly as proxy lambda to API gatway because the stage name is passed through
As seen on [this example page](https://github.com/awslabs/aws-lambda-rust-runtime/blob/main/examples/http-axum/src/main.rs), you are using axum to route the incoming request.

I have a router set up something like this:
```
pub fn get_router() -> axum::Router {
    // With Routing, order does matter, so put the more specific first and then more generic routes later
    Router::new()
        .route(
            "/message/conversation/:conversation_id/message/:message_id",
            get(route_handlers::message::get_message),
        )
        .route(
            "/messages/conversation/:conversation_id",
            get(route_handlers::message::get_messages_by_conversation_id),
        )
        .route("/*path", get(catch_get).post(catch_post)) // just for catching and client feedback
        ...
 ```
 
 This lambda works great when tested from the AWS Lambda console, but fails when called from the API gateway. 

```
aws apigateway test-invoke-method --rest-api-id 5oclxtbcq3 --resource-id dnse2ng1jh --http-method GET --path-with-query-string '/conversation/user/c8089eae-5e7d-11ec-94c8-b42e99b5b2c6/conversation/059f27eb-f921-4a8c-b52b-09195f4204be' --region us-east-1
{
    "status": 404,
    "body": "{\"error_message\":\"unknown GET request to route 'test-invoke-stage/conversation/user/c8089eae-5e7d-11ec-94c8-b42e99b5b2c6/conversation/059f27eb-f921-4a8c-b52b-09195f4204be'\"}",
    "headers": {
        "X-Amzn-Trace-Id": "Root=1-65a8480d-fa17b2d9ea4b2aa6dc4f88c8;Sampled=0;lineage=b2a823c1:0",
        "content-length": "173",
        "content-type": "application/json"
    },
    "multiValueHeaders": {
        "X-Amzn-Trace-Id": [
            "Root=1-65a8480d-fa17b2d9ea4b2aa6dc4f88c8;Sampled=0;lineage=b2a823c1:0"
        ],
        "content-length": [
            "173"
        ],
        "content-type": [
            "application/json"
        ]
    },
    "log": "Execution log for request 3c07bc93-1162-46de-8d78-fffc80a37d8a\nWed Jan 17 21:35:09 UTC 2024 : Starting execution for request: 3c07bc93-1162-46de-8d78-fffc80a37d8a\nWed Jan 17 21:35:09 UTC 2024 : HTTP Method: GET, Resource Path: /conversation/user/c8089eae-5e7d-11ec-94c8-b42e99b5b2c6/conversation/059f27eb-f921-4a8c-b52b-09195f4204be\nWed Jan 17 21:35:09 UTC 2024 : Method request path: {}\nWed Jan 17 21:35:09 UTC 2024 : Method request query string: {}\nWed Jan 17 21:35:09 UTC 2024 : Method request headers: {}\nWed Jan 17 21:35:09 UTC 2024 : Method request body before transformations: \nWed Jan 17 21:35:09 UTC 2024 : Endpoint request URI: https://lambda.us-east-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:us-east-1:11:
```

I have not configured any stage for this API but still the `test-invoke-stage` prefix in on the api request.

How can I remove this or deal with it in the router?


Discussion / hints:

Fix patch:
diff --git a/lambda-http/README.md b/lambda-http/README.md
index 464be88b..4866d071 100644
--- a/lambda-http/README.md
+++ b/lambda-http/README.md
@@ -175,7 +175,7 @@ pub fn custom_authorizer_response(effect: &str, principal: &str, method_arn: &st
 }
 ```
 
-## Passing the Lambda execution context initialization to the handler
+### Passing the Lambda execution context initialization to the handler
 
 One of the [best practices](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html) is to take advantage of execution environment reuse to improve the performance of your function. Initialize SDK clients and database connections outside the function handler. Subsequent invocations processed by the same instance of your function can reuse these resources. This saves cost by reducing function run time.
 
@@ -229,3 +229,9 @@ pub async fn function_handler(dynamodb_client: &aws_sdk_dynamodb::Client, event:
     Ok(response)
 }
 ```
+
+## Integration with API Gateway stages
+
+When you integrate HTTP Lambda functions with API Gateway stages, the path received in the request will include the stage as the first segment, for example `/production/api/v1`, where `production` is the API Gateway stage.
+
+If you don't want to receive the stage as part of the path, you can set the environment variable `AWS_LAMBDA_HTTP_IGNORE_STAGE_IN_PATH` to `true`, either in your Lambda function configuration, or inside the `main` Rust function. Following the previous example, when this environment variable is prevent, the path that the function receives is `/api/v1`, eliminating the stage from the first segment.


Test patch: