URL.host is added as path component and prevents route matching about jlroutes

[joeldev]

Sorry for the trouble, everyone. I just reverted the changes made in this commit (e9536fd).

[abbasmousavi]

This commit, breaks route matching on iOS 9. @radianttap.
I have comment it out in my code and route matching is working again.

[zats]

We ran into the same issue, our scenario is that we are using router both for external universal links (https://myapp.com/path) and for internal links (myapp://path), also we need to support several environments, so in our case universal links can be https://dev.myapp.com/path or https://staging.myapp.com/path or https://myapp.com/path

Also for universal links we support links opened from emails, e.g. https://email.myapp.com/path and links opened from web, e.g. https://web.myapp.com/path. Currently we are working around it by replacing host with localhost prior to sending it to JLRoutes

I'm not sure I understand the reasoning behind this change, not sure if I've seen other routing solutions to match against the host (similar ruby libraries for example)

[ekampf]

Traced back to this commit: 98febf4#diff-49786c8b72bf93a052e6bbaf95b8b295R444

@joeldev is the intended behaviour that route has to contain the host? seems odd...

[joeldev]

I'm going to close this issue for now. Please feel free to re-open (or file another issue) if me reverting that commit has caused some other issue. All current tests are passing and I'm always looking to add more.

[zats]

Thank you

[mjarvis]

@joeldev This issue appears to be reoccurring. JLRRouteRequest.m:L33-38 adds the host as a path component. Is this an intentional change for 2.0? It does not match the routing behaviour from the 1.x versions of JLRoutes.

Here is a failing test that indicates this problem:

- (void)testHostIgnored
{
    [[JLRoutes globalRoutes] addRoute:@"/someRoute/123"
                              handler:[[self class] defaultRouteHandler]];

    [self route:@"https://google.com/someRoute/123"];
    JLValidateAnyRouteMatched();
}

If this is intentional, it would be a good idea to document the change in behaviour in the 2.0.0 release notes and possibly a "migrating to 2.x" document, as people will need to add manual stripping of the host to bring back the old behaviour.