Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing query strings with keys of the same name #62

Open
alexmingoia opened this issue Oct 22, 2015 · 3 comments
Open

Parsing query strings with keys of the same name #62

alexmingoia opened this issue Oct 22, 2015 · 3 comments

Comments

@alexmingoia
Copy link

The browser behavior (and standard if I can dig up the forms spec) of HTML forms with array-like values is to include a query string with repeated keys.

This multi-select:

<select name="colors" multiple>
  <option value="orange">orange</option>
  <option value="purple">purple</option>
</select>

Will result in ?colors=orange&colors=purple if both options are selected. Instead of parsing this as a list, parseQuery ignores the second value. Furthermore, the query is represented as a lookup map of bytestrings, so has no notion of multiple values per key.

The reason I bring this issue up is this use case: basic HTML form with a multi-select and no JS and a haskell backend using http-types. The http-types Query type and parsers fail that use case.

@aristidb
Copy link
Owner

Fair point. How about this?
We leave Query and QueryItem as is, but make a generic Query-like type that allows putting in Maybe or [], and we just use a generic "append" operation that either replaces or adds an element.

I would most welcome pull requests for this! :-)

@aristidb
Copy link
Owner

To clarify: The parseQuery function would always work in terms of the generic type.

@Vlix
Copy link

Vlix commented Nov 30, 2023

I'm pretty sure parseQuery just creates a list of key-value pairs. (at least currently)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants