match-pair no longer supports decoded paths

[Haus]

Prior to bidi 1.25.0, routes with decoded spaces in them were handled and passed to the appropriate handler. Beginning in bidi 1.25.0, routes with decoded spaces in them throw a URISyntaxException. This is because java.net.URI throws an exception if it is passed a string with invalid URI characters.

dev-tools=> (java.net.URI. "foo bar")

URISyntaxException Illegal character in path at index 3: foo bar  java.net.URI$Parser.fail (URI.java:2848)
dev-tools=> (java.net.URI. "foo%20bar")
#object[java.net.URI 0x6465e3f3 "foo%20bar"]

java.net.URI began being used in bidi/just-path in #105, 15708c9.

In our use of bidi, we have it sitting behind a webserver that is already decoding URIs before handing them to the routing layer, to ensure that all decoding and normalization happens at the same place (we use jetty's URIUtil and call decodePath followed by canonicalPath). I was hoping that someone might have an idea of how to make match-pair opt into the old behavior of tolerating decoded spaces in the inputs.

Here is a simple reproducer of the old and current behaviors.

Using bidi 1.23.1

dev-tools=> (require '[bidi.bidi :as bidi])
nil
dev-tools=> (bidi/match-pair [#"/.*" (constantly nil)] {:remainder "/que/foo%20bar"})
{:handler #object[clojure.core$constantly$fn__4614 0x3a7ccefc "clojure.core$constantly$fn__4614@3a7ccefc"]}
dev-tools=> (bidi/match-pair [#"/.*" (constantly nil)] {:remainder "/que/foo bar"})
{:handler #object[clojure.core$constantly$fn__4614 0x60aab317 "clojure.core$constantly$fn__4614@60aab317"]}

Using bidi 2.0.12

dev-tools=> (require '[bidi.bidi :as bidi])
nil
dev-tools=> (bidi/match-pair [#"/.*" (constantly nil)] {:remainder "/que/foo bar"})

URISyntaxException Illegal character in path at index 16: file:////que/foo bar  java.net.URI$Parser.fail (URI.java:2848)
dev-tools=> (bidi/match-pair [#"/.*" (constantly nil)] {:remainder "/que/foo%20bar"})
{:handler #object[clojure.core$constantly$fn__4614 0x6ad64b4c "clojure.core$constantly$fn__4614@6ad64b4c"]}

[Dominic Monroe]

The behaviour is now the same in both cases as of 2.1.5. Although there may be characters for which this is not true. Anything that's valid in a URL will now work, spaces included.

[Haus]

Oh awesome. That's perfect. Thank you! 2.1.3 is working.