When parsing a URL if the path contains a query string at the end e.g. /api/something?a=b&c=d given a rule of /api/:what the value of the query string ends up being appended to parameter - in this example match.params["what"] == "something?a=b&c=d".

It would make sense to introduce the concept of the query string at least and remove it from the last match entry when producing the parameter map.

Hello, I'm trying to fix iron/router to get the Heroku example program working again, and it looks like the crates.io version of route-recognizer is out of date. Could we please have a new package? :-)

(Also, is there a better stack to use than iron, for demo purposes? conduit looks interesting but there are no docs that I can find yet.)

Hi, I created an issue on tide http-rs/tide#690 that was asking about the possibility to adding routing on subdomains as well as on paths. I noticed that it isn't a highly requested feature but I'm using tide for a small app I'm building and need the support to be able to route on subdomains.

However, looking at the code right now, I believe that adding support for subdomains make create some breaking changes. I am just wondering if it would be ok to work on this issue or if there should be more planning happening up front to add this feature into the repository.

i want to benchmark this package with https://github.com/gin-gonic/go-http-routing-benchmark

but it doesn't compile with rust-nightly
Compiling route-recognizer v0.1.0 (file:/home/redar/ed/route-recognizer.rs)
src/nfa.rs:245:11: 245:24 error: cannot determine a type for this local variable: cannot determine the type of this integer; add a suffix to specify the type explicitly
src/nfa.rs:245 let mut count = 0;
^~~~~~~~~~~~~
src/lib.rs:46:1: 48:2 error: not all trait methods implemented, missing: partial_cmp
src/lib.rs:46 impl PartialOrd for Metadata {
src/lib.rs:47 fn lt(&self, other: &Metadata) -> bool { self.cmp(other) == Less }
src/lib.rs:48 }
error: aborting due to 2 previous errors
Could not execute process rustc src/lib.rs --crate-type lib --out-dir /home/redar/ed/route-recognizer.rs/target -L /home/redar/ed/route-recognizer.rs/target -L /home/redar/ed/route-recognizer.rs/target/deps (status=101)

Consider a path, /path/:value/?foo=:bar parsed with url /path/test/?foo=something. The library currently parses only test parameter, ignoring the foo query parameter. It should parse that as well.

The implementation of prioritising routes based on the specificity of their pattern introduced in e5047b8 is nice, but I believe the ordering is the reverse of what it should be.

I think if you have a mixture of static, dynamic and star components in the path the most specific path should be preferred (i.e. /index.html > /:segment > /*path). Simple cases like this work (as does the test case provided in the referenced commit) but not because of the ordering conditions but rather because in this simple case the higher priority paths contain none of the lower priority components.

Consider instead /archive/*path vs /*path and you see that the ordering constraints as currently implemented do the reverse in that /*path (the least static) is the preferred path.

I believe instead the ordering should be as follows:

    if self.statics > other.statics {
        Ordering::Greater
    } else if self.statics < other.statics {
        Ordering::Less
    } else if self.dynamics > other.dynamics {
        Ordering::Greater
    } else if self.dynamics < other.dynamics {
        Ordering::Less
    } else if self.stars > other.stars {
        Ordering::Greater
    } else if self.stars < other.stars {
        Ordering::Less
    } else {
        Ordering::Equal
    }

The ordering of the final stars comparison could go either way. As I have proposed it here, the path /*pre/and_then/*post is preferred over /archive/*path because the latter is least specific (containing only two components versus three). An alternative would be to ignore the number of stars in the ordering and fall back to the default ordering so long as it is deterministic.

I believe the default ordering currently is such that if two matches are equal (based on metadata ordering) then the first defined is chosen (please correct me if I am wrong). A deterministic default ordering (or else an explicit one) is required because I don't believe there is any sensible way to automatically decide between /archive/*path and /*path/meta

Is the crate alive? If not, what's an alternative?

You can define a path without naming the parameters e.g. /api/* or /api/:/something

The value at that position is parsed and then stored in the parameters and can be retrieved using an empty string match.params[""]

Conceptually unnamed parameters makes sense where you want to match the path but don't need a capture group for it - however it should not store the value in the map.

Here's two failing examples:

use route_recognizer::Router;

fn main() {
    let mut router = Router::new();
    router.add("/foo%2Fbar", "Hello".to_string());
    router.add("/foo bar", "Hello".to_string());

    assert_eq!(
        router.recognize("/foo%2fbar").unwrap().handler().as_str(),
        "Hello"
    );

    assert_eq!(
        router.recognize("/foo%20bar").unwrap().handler().as_str(),
        "Hello"
    );
}

Ref: http-rs/tide#783

curl http://localhost:8080/test
ok
curl http://localhost:8080/
404
curl http://localhost:8080
404

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright) and then add the following to
your README:

## License

Licensed under either of
 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, use the following boilerplate (based on that used in Rust):

// Copyright (c) 2016 route-recognizer.rs developers
//
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. All files in the project carrying such notice may not be copied,
// modified, or distributed except according to those terms.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @alexcrichton
• @wycats
• @reem
• @Nercury
• @andor44
• @darayus
• @aleksandrpak
• @miller-time
• @sfackler
• @Nemo157

This blocks being able to make a route like /crates/:crate_id.svg

panic: byte index 12 is not a char boundary; it is inside '打' (bytes 10..13) of `crates/实打实打算/d's'd`
  File "panicking.rs", line 515, in rust_begin_unwind
  ?, in route_recognizer::nfa::Thread::extract
  ?, in route_recognizer::nfa::NFA<T>::process
  ?, in route_recognizer::Router<T>::recognize
  ?, in conduit_router::RouteBuilder::call
...
(32 additional frame(s) were not displayed)

this can be reproduced by:

#[test]
fn test_chinese() {
    let mut router = Router::new();
    router.add("/crates/:foo/:bar", "Hello".to_string());

    let m = router.recognize("/crates/实打实打算/d's'd").unwrap();
    assert_eq!(m.handler().as_str(), "Hello");
    assert_eq!(m.params().find("foo"), Some("实打实打算"));
    assert_eq!(m.params().find("bar"), Some("d's'd"));
}

When I use route-recognizer like you use it in conduit-router clippy complaints that &Handler always is better than &Box<Handler>.

When you store the Router destinations in a box, the return type of recognize() ends up being &'a Box<Handler>.

I added a HeapRouter that takes boxed things and returns references to the inner type instead. Is this a good way to deal with this lint or do you suggest some other way?

NickeZ@66e928e

Hey there, thanks for this cool library :)

I'm writing an application that needs to capture params that are paths. Is it possible to do it?

Example

    router.add(
        "/delete/:path",
        DeleteFileScreen
    );

Then I'd like to match something like this:

match router.recognize("/delete/home/user/example/foo/bar")

Essentially I would like something like Flask's PATH url converter: https://flask.palletsprojects.com/en/2.0.x/quickstart/#variable-rules.

Thank you

Hi! I was investigating a tide routing issue (http-rs/tide#593) and discovered that it's resolved on master but not in 0.1.13. It must have been a subtle bug, because it doesn't seem like any of the changes between master and 0.1.13 directly address this.

This is a route-recognizer test case that fails in 0.1.13 but passes in master:

#[test]
fn ambiguous_router_wildcard_vs_star() {
    let mut router = Router::new();
    router.add("/:one/:two", "one/two".to_string());
    router.add("/posts/*", "posts/*".to_string());
    let id = router.recognize("/posts/10").unwrap();
    assert_eq!(*id.handler, "posts/*".to_string());
}
/*
0.1.13: 
---- ambiguous_router_wildcard_vs_star stdout ----
thread 'ambiguous_router_wildcard_vs_star' panicked at 'assertion failed: `(left == right)`
  left: `"one/two"`,
 right: `"posts/*"`'

Master: passes
*/

As a side note, it also seems that there's a breaking change regarding anonymous wildcards. This test case passes in 0.1.13, but fails on master:

#[test]
fn anonymous_wildcard() {
    let mut router = Router::new();
    router.add("/a/:/:c", "".to_string());
    let route = router.recognize("/a/10/20").unwrap();
    assert_eq!(route.params, two_params("", "10", "c", "20"));
}

/*
0.1.13: Passes

Master:
---- tests::anonymous_wildcard stdout ----
thread 'tests::anonymous_wildcard' panicked at 'assertion failed: `(left == right)`
  left: `Params { map: {"c": "20"} }`,
 right: `Params { map: {"": "10", "c": "20"} }`'
*/

I don't think this regression is especially important for tide, but it would be very nice to have a release with the first fix.

Thanks!

You can currently define duplicate named parameters in the route with the last one resolved being the end value. E.g. given the following:

#[test]
fn duplicate_key() {
    let mut router = Router::new();

    router.add("/foo/:bar/*bar", "test".to_string());
    let m = router.recognize("/foo/blah/this/is/the/rest").unwrap();
    assert_eq!(*m.handler, "test".to_string());
    assert_eq!(m.params, params("bar", "blah"));
}

this fails with:

thread 'duplicate_key' panicked at 'assertion failed: `(left == right)`
  left: `Params { map: {"bar": "this/is/the/rest"} }`,
 right: `Params { map: {"bar": "blah"} }`', src\lib.rs:339:5

This should probably be prevented when the route is created - given that you can define nameless parameters I can't see a reason for needing to have duplicate names.

This would be pretty nice, specially considering a future macro that can catch overlap at compile time (as suggested in iron/router#48 (comment)). How difficult would it be to implement this?

Now that we have maintainers for this crate I think it's about time there were fixes to long standing issues like #20. It's probably worth making this a breaking update to avoid any issues with unmaintained users of the current version (and would be a good opportunity to make other breaking changes if there are any).

Checklist of things to sort out before releasing 0.2.0 (feel free to add more items and pull these out to separate issues if they need discussion):

• Issues:
  • #20 (PR #21)
  • #16
  • #29 (PR #31)
  • #30
  • #34
• Sort out licensing (#19 + the repo is missing license files for the current license, PR #32).
• rustfmt + clippy (PR #27)
• Update travis config (rustfmt + clippy, stable + beta + nightly, minimum Rust version) (PR #33)
• Update metadata (at a minimum links + authors in Cargo.toml, PR #37)
• Improve documentation
• Update to 2018 edition (PR #38)

I would like to know how to prevent replacing a route with other