Encoding / Decoding issue

[NicoD]

The bracket characters (unsafe) and equal character (reserved) are directly set in the url query string or fragment without encoding.

example:
https://demo.algolia.com/instant-search-demo/?q=&hPP=10&idx=instant_search&p=0&nR[price][>=][0]=2676&is_v=1
should be:
https://demo.algolia.com/instant-search-demo/?q=&hPP=10&idx=instant_search&p=0&nR%5Bprice%5D%5B%3E%3D%5D%5B0%5D=2676&is_v=1

(same thing observed with useHash = true)

[vvo]

Hi @NicoD this should be handled by the browsers in a natural way: the url looks good and can be copy pasted in a url bar, did you observe any bad behavior?

[NicoD]

Hi @vvo ,

here some examples with a failure:

• here in github, in my previous comment. When I copied the first url (which is the instantsearch url), github had itself encoded the unsafe characters (brackets) but not the =. The link does not work when following it. (however the second link - which i encoded manually - works fine)
• i had the same issue when reading an instantsearch url through a slack client (not the web client)

=> i suppose this error may happened on others clients that encode the query string: the brackets are normaly url urlencoded, but not the = which is considered as a separator.

• js url parsing lib (like urljs and browserify url) fail parsing the query string or fragment because of the = and the non encoded chars.

I think it would be safer to urlencode all the reserved and unsafe chars in the query string and the fragment (https://tools.ietf.org/html/rfc3986)

[vvo]

@NicoD As for copy pasting the url from the urlbar or right click a link and copy from the context menu then paste it anywhere => it's the responsibility of the client to do things well. Github does, slack also it seems

On this issue, I was able to fix it by decoding the uri every time its needed (loading the page, back button): decodeURIComponent.

Seems to work well, let me know. The fix is incoming

[vvo]

This is not as easy as I thought, decoding when receiving has his owns quirks: values (facet refinements) with & or = are decoded and then mis interpreted as separators.

[vvo]

To completely solve this issue we will have to stop trying to be smart in the helper: trying to only encode values and not param delimiters.

We should just use encode: true from qs/ module because what we did was worse: encoding values while not encoding param separators like []. It turns out that this is not well supported in cases where you copy paste the url.

I am sorry I am the one that thought this would be feasible but it's not. We must encode everything and thus have not so good looking uris.

cc @bobylito would you be ok removing our custom encoding code from the helper and just use encode: true from qs?