-
-
Notifications
You must be signed in to change notification settings - Fork 732
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
Comma-delimited array parsing fails when individual items contain commas #311
Comments
Setting |
actually on a second look, that's supposed to be the default. In that case, that sounds like a bug. a PR would be welcome. |
FWIW, adding the |
it's a bug, I'll fix it later |
When I try to fix this issue, it has a lot of confusion.
What is expected after we stringify that object? |
@daggerjames i would expect |
Hello, any news regarding this issue? Really hope it will be fixed |
@quentinus95 #336 (comment) - it's a breaking change currently, and @Om4ar hasn't updated the PR to make it not be one. If anyone else has an update for the PR, post a link to a branch on it (NOT a new PR) and i'll pull it in. |
@ljharb this ticket should be kept open, the merged PR does not fix the issue. Please see my comment on the PR. As I wrote, if you have any suggestion to fix the issue without doing a large refactoring, I'll be happy to write the implementation. Thanks! |
Comma-delimited array parsing fails when running something like this:
Expected:
{ things: ['a, b', 'c, d'] }
Actual:
{ things: ['a', ' b', 'c', ' d'] }
Per my understanding of RFC 3986, a percent-encoded comma should not be treated the same as a comma literal. Comma literal is a reserved character used for delimiting parameters and parameter values, but a percent-encoded comma is not.
My use case needs to deal with arbitrary user input within values, potentially including commas.
I guess this can be fixed with a custom
decoder
function, but it seems like something that should work by default whencomma
istrue
.As my use case is otherwise fairly simple and I don't need lots of custom features, I figured I'd just roll my own query string parser/serializer. I'm linking to this strictly for reference and wouldn't recommend anyone to use it in production in its current state - it probably diverges from the RFC in a million other ways and fails for lots of edge cases that aren't relevant to my specific use case.
Related: #237 (but that deals with
stringify
, whereas this is aboutparse
).The text was updated successfully, but these errors were encountered: