Throwing errors for segments that are not properly encoded on .add(...) and .match(...)

[matthewdunsdon]

There is a desire for add and match to throw errors for segments that are not properly encoded:

add and match are input conservative and throws errors on invalid paths, however they should resolve relative paths, in so far as they should add a leading slash if it's missing, and remove a trailing slash if it's there

(taken from #18 (comment))

Currently, this does not take place.

[matthewdunsdon]

A question I raised from #19 (comment):

Do you agree that we should throw errors for segments that are not properly encoded?

An example of a route or path that has not been encoded correctly is /path with spaces/&more@invalid,characters, though we could see encoding issues with the content that is before or after a partial variable.

We could suggest that users make use of the currently in development rhumb.interpolate(...) method to encode paths. This would ensure rhumb can remain liberal with the input it accepts, at least for paths. As interpolate(...) is designed to interpolate variables, we can not use this to clean up or fix routes, such as handling the encoding of '/install(/@{scope})/{package}' into '/install(/%40{scope})/{package}'.

---

As part of this, I was asking whether .add(...) and .match(...) need to be able to take the information that parse gives them and identify whether the segments are properly encoded.

We could do this by parse taking a path or route and having it validate fixed segments and labelled them if they have un-encoded characters. The parse consumers .add(...) and .match(...) could take this and produce as an error. The parse consumer interpolate(...) could take this and actually encode the characters in that fixed segment.