Reconsider behaviors when the route is not matched

[ubnt-intrepid]

It is unclear how to treat the scope information when the route matched to incoming request is not indeterminate, and it makes difficult to properly handle the error management in CORS, session management, etc. It is necessary to clarify the behavior for handling the recognize errors.

[ubnt-intrepid]

The case when the path is not recognized

In this case, the following two assumption are considered:

• The recognizer has no information to determine the scope information. Features related to the scope are ignored, or it assumes that the current context belongs to the global scope.
• The recognizer guess the scope using partially matched prefix. If there are multiple candidates, their common parent is selected.

For example, consider the following situation:

app!()
  .mount(
    scope!("/foo")  // <-- (S1)
      .mount(scope!("/bar/baz"))  // <-- (S2)
      .mount(scope!("/bar/foo"))  // <-- (S3)
  )

When a request that has the path such as /foo/bar comes, it is obvious that its scope is either S1, S2 or S3, and it is intuitive that the error handler called at this time is the one registered in S1.

The case when the path is recognized but the method is incorrect

In this case, the scope identifier could be uniquely determined by assuming that the all routes that have the same path must be belong to the same scope.

[ubnt-intrepid]

The behavior when the route is undetermined has been fixed in #188. The recognizer will return a set of candidates of partially matching routes, and infers the scope identifier of the incoming URL based on its information.