querystringify: Does not decode plus signs

This test fails:

describe('#parse', function () {
  it('will decode plus signs', function () {
    var obj = qs.parse('foo+bar=baz+qux');

    assume(obj).is.a('object');
    assume(obj["foo bar"]).equals('baz qux');
  });
});

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (10 by maintainers)

Commits related to this issue

[fix] Convert plus signs to spaces Fixes #7 — committed to unshiftio/querystringify by lpinca 7 years ago
[fix] Convert plus signs to spaces Fixes #7 — committed to unshiftio/querystringify by lpinca 7 years ago
[fix] Convert plus signs to spaces (#8) Fixes #7 — committed to unshiftio/querystringify by lpinca 7 years ago

Most upvoted comments

I see no reason to turn + into a space.

m59peacemaker on Mar 18, 2017

I t does look nice. If you care to discuss a little further - I’m not sure you see the way I’m thinking about it (and it appears @3rd-Eden had the same thought). The best that I can understand it, 3986 says that the URI should be percent-encoded except the characters which have particular meaning to the scheme. There are characters which a scheme is allowed to use as delimiters to express whatever kind of thing it needs to. + is one of those allowed characters, but it is to be percent-encoded by default unless the scheme considers it a delimiter.

I discovered that application/x-www-form-urlencoded is the only scheme that uses + in its spec and in that, + represents a space.

Things get frustrating in my mind from there - what if there were new kinds of schemes and one said that + should mean something else? Do all the query string utilities have to add more options to that + can be a space or something else? Complex stuff! As it is, I still conclude that + has no meaning to every other scheme and technically shouldn’t change it, but then you have to specifically support the one scheme that wants it to be a space. I’m mostly just curious about all this. There’s not a good discussion anywhere about it that I’ve found. Don’t spend precious time thinking about it if it’s a bother!

m59peacemaker on Mar 21, 2017

It’s there now btw.

3rd-Eden on Mar 20, 2017

I’ll go ahead and merge #8. @3rd-Eden can then release a new version when he has some spare time.

lpinca on Mar 20, 2017

Technically, our implmentation is correct because the name of the parameter is indeed foo+bar if it was encoded by the browsers it would have been %20 instead of + so that has been added manually or is done by a transformation process.

3rd-Eden on Jan 23, 2017