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

Option to avoid percent-encoding sub-delims such as commas #237

Open
jchook opened this issue Dec 4, 2017 · 3 comments
Open

Option to avoid percent-encoding sub-delims such as commas #237

jchook opened this issue Dec 4, 2017 · 3 comments

Comments

@jchook
Copy link

jchook commented Dec 4, 2017

According to RFC 3986, the query string of a URI may contain sub-delims (including commas). Can we have an option to avoid percent-encoding them? Or possibly don't encode them by default?

Rationale

Leaving allowed sub-delims unencoded results in far more readable query strings with better overall usability. E.g., alpha,beta,gamma is better than alpha%2Cbeta%2Cgamma.

The RFC actually hints at the importance of this in section 3.4. In reference to percent-encoding / and ?, two examples of reserved delimiters that are allowed in query strings, it states:

...it is sometimes better for usability to avoid percent-encoding those characters.

I'm sure there are others, but one prominent use case is the include parameter in JSON API, as well as its filter recommendations.

Possible syntax

We could offer fine-grained control over which sub-delims are not percent-encoded.

jq.stringify(obj, {allowChars: [',']});
@SuitespaceDev
Copy link

SuitespaceDev commented May 26, 2022

sub-delims should generally be used by your application or URL decoding algorithm but not as actual names of resources. i.e., it is OK for your site to have links to
example.com/category;cat=pencils/product;v2.4/pencil;id=44/?param=value

no problem

but the actual resources routed to should exist with or without the sub-delimited strings
example.com/category/product/pencil should still reach the same script and only your routing algorithm should be able to tell it anything about the sub-delim text

the way routing tells those characters apart from the real path, are by them not being encoded.
sooo you don't want to break that behavior.

If you can solve this with respect that intent and are careful not to break similar usage in the query string (such as wordpress array query parameters or OData's use of parenthesis) then it should be a viable solution with nothing to worry about

@thisIsTheFoxe
Copy link

Hi, just a +1 from me, I think query parameters should always be as readable as possible and allow users to see and possibly even edit them themselves. And the current default (using 'indices' and percent encoding) is pretty much the opposite of that and what I would've expected ('a%5B0%5D=b&a%5B1%5D=c&a%5B2%5D=d' looks like a token or sth).

However, you can configure it which is awesome! Just took me a while to figure it out:

const existingQueries = qs.parse(location.search, {
  comma: true
});

const queryString = qs.stringify(
  { ...existingQueries, [query]: value },
  { arrayFormat: 'comma', encodeValuesOnly: true }
);

a=b,c,d

Just be careful as that also means if only one element is present it's returned as string, not array.

@ljharb
Copy link
Owner

ljharb commented Mar 2, 2024

@thisIsTheFoxe thats what the commaRoundTrip option is for

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

No branches or pull requests

4 participants