This PR gets most tests to pass using net/url.String() for url escaping. The only failing tests are for EncodeNecessaryEscapes and DecodeUnnecessaryEscapes, which rely on implementation details of net/url and urlesc.
It is remarkably difficult to avoid net/url's escaping logic, especially if you try to hold it "right" by using .String(), .EscapedPath(), PathJoin(), &c. My opinion is that net/url has had this escaping logic for years at this point and likely folks should be OK with it at this point.
In addition, the TestEncodeNecessaryEscapesAll is vague; as written, it tests not only the path but also query and fragment escaping, since the url string contains ? and #. It is unclear to me if we want to just test path escaping or if we care about query and fragment escaping too?
This PR gets most tests to pass using
net/url.String()for url escaping. The only failing tests are forEncodeNecessaryEscapesandDecodeUnnecessaryEscapes, which rely on implementation details ofnet/urlandurlesc.It is remarkably difficult to avoid
net/url's escaping logic, especially if you try to hold it "right" by using.String(),.EscapedPath(),PathJoin(), &c. My opinion is thatnet/urlhas had this escaping logic for years at this point and likely folks should be OK with it at this point.In addition, the
TestEncodeNecessaryEscapesAllis vague; as written, it tests not only the path but also query and fragment escaping, since the url string contains?and#. It is unclear to me if we want to just test path escaping or if we care about query and fragment escaping too?Resolves #14 unsatisfactorily.