-
-
Notifications
You must be signed in to change notification settings - Fork 731
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
Comments
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 no problem but the actual resources routed to should exist with or without the sub-delimited strings the way routing tells those characters apart from the real path, are by them not being encoded. 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 |
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 ( 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 }
);
Just be careful as that also means if only one element is present it's returned as string, not array. |
@thisIsTheFoxe thats what the |
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 thanalpha%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:I'm sure there are others, but one prominent use case is the
include
parameter in JSON API, as well as itsfilter
recommendations.Possible syntax
We could offer fine-grained control over which sub-delims are not percent-encoded.
The text was updated successfully, but these errors were encountered: