Normalize query parameters #1691

Is your feature request related to a problem? Please describe.

The same Lambda function receives different query-parameter values depending on its HTTP integration.

For this request:

?full_name=Alex+Taylor

a Lambda Function URL provides:

{
  queryStringParameters: {
    full_name: "Alex Taylor"
  }
}

An Application Load Balancer Lambda target provides:

{
  queryStringParameters: {
    full_name: "Alex+Taylor"
  }
}

AWS documents that ALB does not decode URL-encoded query parameters before invoking Lambda:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html

This means application code can behave differently when the same Lambda is moved between or invoked through these integrations.

Describe the solution you'd like

I would like feedback on whether Middy should offer an opt-in way to normalize ALB query parameters so they behave consistently with Lambda Function URL and API Gateway events.

The normalization would need to use query-string/form semantics, such as URLSearchParams, rather than only decodeURIComponent:

Alex+Taylor   → Alex Taylor
Alex%20Taylor → Alex Taylor
Alex%2BTaylor → Alex+Taylor

It should support both queryStringParameters and multiValueQueryStringParameters and apply only to ALB events, since decoding an already-decoded event could change its meaning.

I am not sure whether this belongs in a new middleware, as an opt-in option on an existing HTTP middleware, or outside Middy. I would appreciate guidance from the maintainers and community before proposing an implementation.

Describe alternatives you've considered

• Handling the difference in every Lambda handler. This duplicates integration-specific behavior across application code.
• Writing a project-specific middleware using URLSearchParams. This works, but the behavior appears generally applicable to Lambdas invoked through ALB.
• Using @middy/http-urlencode-path-parser. This handles path parameters and intentionally uses path-decoding semantics; it does not handle form-encoded query parameters where + represents a space.
• Using @middy/http-event-normalizer. This ensures parameter objects exist but does not decode their keys or values.
• Converting the complete ALB event into an API Gateway or Function URL event. This is more invasive than normalizing the affected query parameters.

Additional context

@middy/http-router already supports ALB events directly. This request is not about converting the complete ALB event or adding routing support. It is about whether Middy should provide an opt-in normalization layer for the query-parameter behavior that differs between supported HTTP event sources.