Support multiple HTTP parameter with same key

[klaus0x7c4]

It is common you have cases like: http://example.com/action?id=a&id=b
The current implementation uses a map for the parameter list. So you currently only get the value id=b from the example above.

[UncannyBingo]

That is true. RFC 3986 doesn’t define behavior for this case, in fairness.

Still, this seems like something we should support. How would you envision the Luna API behaving in cases with multiple Parma’s with the same key?

[klaus0x7c4]

The easiest way for luna would be to keep a list or vector of string pairs instead of the map. Or a map like: std::map<std::string, std::vector<std::string>>. But all that seems to be a breaking change for luna.

The meaning of several identical keys must be clarified by the user in the request handler (or another callback?).

Or you have access to the unparse parameter list next to the map. But I think that's just a quick and dirty solution.

It's hard for me to say what's the right way. The simple vector of string pairs would be enough for me for now.

[UncannyBingo]

What about std::multimap? Still a breaking change, but perhaps less drastic?

[klaus0x7c4]

I didn't know the multimap yet. That sounds good.
Maybe the std::unordered_multimap is also an option.
If I understood it correctly, it is a choice between performance and memory usage:

• http://www.cplusplus.com/reference/map/multimap/
• http://www.cplusplus.com/reference/unordered_map/unordered_multimap/

[UncannyBingo]

Yes, we should I think prefer the performance of the std::unordered_multimap. I think in general the number of parameters will be small enough that memory is not an issue—although we might like to gird our loins against DoS attacks that attempt large numbers of query params in the future.