allow customized User_Agent for lambda runtime api client #454
Conversation
There was a problem hiding this comment.
I think this would be better as a runtime environment variable, so people could differentiate requests from the same compiled function in different environments.
So, instead of making it a const with option_env!, I would use std::env::var in the Client's initialization and add it to the request builder when it's not empty.
|
We want to track the usage of AWS Lambda Adapter. Users of Lambda Adapter are not supposed to change the User-Agent. |
|
Thanks for the suggestion. It is done. :) |
Agree with this. The use-case for changing the User-Agent is pretty niche, and not something end-users need to do. |
| @@ -14,7 +14,8 @@ use tokio::io::{AsyncRead, AsyncWrite}; | |||
| use tower_service::Service; | |||
|
|
|||
| const USER_AGENT_HEADER: &str = "User-Agent"; | |||
| const USER_AGENT: &str = concat!("aws-lambda-rust/", env!("CARGO_PKG_VERSION")); | |||
| const DEFAULT_USER_AGENT: &str = concat!("aws-lambda-rust/", env!("CARGO_PKG_VERSION")); | |||
| const CUSTOM_USER_AGENT: Option<&str> = option_env!("LAMBDA_RUNTIME_USER_AGENT"); | |||
There was a problem hiding this comment.
@bnusunny , Harold, sorry for nit-picking, but it would be nice to have the explanation in the comments for the future us.
// Use of custom value was requested by https://github.com/aws-samples/aws-lambda-adapter for internal AWS needs. It is not something an end user would want to change and the value is not propagated to CloudWatch. See #452
Issue #, if available:
#452
Description of changes:
allow customized User_Agent for lambda runtime api client
By submitting this pull request