`lambda_http::Request` should expose a `QueryMap` from a `raw_query_string`

[adriandelgado]

This is a follow-up to this issue @calavera

I had a new idea while reading closely the Payload format Version 2.0. There is a rawQueryString field! This means we can use this field to correctly parse query parameters into a QueryMap.

The lambda_http crate already appends this raw_query_string into the Uri of the request (as seen in the function request::into_api_gateway_v2_request), and the wrong QueryStringParameters are put inside an extension of the request.

So my idea is... maybe we can also expose theraw_query_string in some way but already parsed into a QueryMap. Something like an extension that can be accessed through the RequestExt trait. My reasoning is that most people using API Gateway expect the QueryStringParameters to behave according to the whatwg spec.

Maybe we can put a warning about this weird quirk of AWS in the documentation of RequestExt::query_string_parameters and push devs to use a new method like raw_query_string.

[calavera]

what if we make the QueryStringParameters use the right parameters by creating a QueryMap from the raw_query_string, instead of the mangled apigw v2 ones? To be honest, I don't believe anyone would expect the current behavior of not parsing commas correctly.

[adriandelgado]

That is much better in my opinion. The reason I didn't propose that is that technically the official behavior is to split at commas, but yes... no one expects that.

We should put a note in the documentation saying that we are not following the API Gateway Payload format Version 2.0 on purpose.

[calavera]

yeah, if someone needs the payload format version 2 behavior, they can use the raw runtime and receive those events specifically, they don't need to use lambda_http.