Was automatic decoding a mistake?

[pshrmn]

Since there have been issues, I thought that it might be appropriate to discuss the pros and cons of automatic pathname decoding in history.

Pros

• Consistent location objects. If history always decodes the pathname, then location object's will always have a decoded pathname. If history does not do this, then locations created from window.location will have an encoded pathname, while locations created from the user will be encoded/unencoded based on what the user provides.
• Unencoded pathnames make route matching easier (for React Router).

Cons

• Makes it difficult if the user wants the pathname to be encoded. This can be because of special handling (like the encoded forward slash Path is decoded in createLocation #505) or because of illegal encoding (Adding a % in the url causes error #481) that some websites (like Google) still support.

Edit: Deleted some stuff here, nothing particularly important.

Perhaps I'm just overthinking this, but whenever I see issues with the current implementation, it makes me think I jumped the gun when I implemented the automatic decoding. It definitely seems like a good idea, but text encoding is difficult/annoying to deal with and I think that it might be better to have consistent behavior than convenience with some edge cases.

[pshrmn]

I just took a look at what Django does, and they also decode pathnames (to the extent that a request for /test%2fing will be matched by r"^test/ing$", which I'm not entirely convinced is the desirable). They also reference RFC 3987, which I should probably take a look at (not sure how relevant it is for history).

I think that the important thing is that the pathname pushed to the browser is what the user provides us. That should be doable while still automatically decoding the pathname. I'll look into a possible PR for this behavior sometime soon.