Support multiple query parameters with the same name

[csmarchbanks]

I am looking at migrating to use huma in a project but one thing that is blocking me is support for requests such as /path?foo=bar&foo=baz. This is especially useful when a value may include a comma which would cause the current comma based approach to fail.

I am happy to implement this feature, and made a start, however I am not sure the best way to get the multiple values out of huma.Context. I could add a new method such as QueryMultiple(name string) []string to the interface, but would that be a breaking change for anyone implementing their own adapter? Happy to hear any suggestions. Worst case I suppose we could cast to a second interface and throw a runtime error?

[danielgtaylor]

@csmarchbanks I'm open to trying to support this. I didn't originally implement it because of performance reasons, i.e. you can avoid all dynamic allocations in the request handling hot path by only having one value per query param name. I think returning []string will require allocations, but I'm open to ideas. The benchmarks in adapters/humachi can be helpful to see how your changes impact memory and garbage collection.

Edit: another option is to support escaping of commas.

[turtledev1]

I'm trying to support the same thing. Currently it is supported by OpenAPI with the parameters "explode: true" and "style: form" (https://spec.openapis.org/oas/v3.1.0#parameter-object). I tried to add these annotations but the resulting json always have the explode property to false, and was confused until I stumbled on this thread.

EDIT: Found the exact line

huma/huma.go

Line 140 in 158b076

// If `in` is `query` then `explode` defaults to true. Parsing is *much*

[ARolek]

I'm also encountering this block. I'm happy to help with code review / testing / etc.

[csmarchbanks]

I finally had some time to implement this and have a PR up at #498, let me know if you run into any issues with it!