Consider adding a way to use strict comparison for routes matching

[Eilon]

From @PinpointTownes on February 6, 2017 4:3

http://stackoverflow.com/questions/42048770/asp-net-core-openiddict-throws-an-openid-connect-response-cannot-be-returned-fr

Consider this action:

[HttpPost("~/path")]
public IActionResult Test() => Empty();

Oddly, either the routing stack or MVC seems to consider /path/ requests as valid candidates for this route/action, which is incorrect as /path and /path/ are two different addresses.

Is there any particular reason for this (abusive) normalization?

/cc @Eilon @rynowak

Copied from original issue: aspnet/Mvc#5757

[Eilon]

From @PinpointTownes on February 6, 2017 7:31

Is there any particular reason for this (abusive) normalization?

After some research, it looks like it matches what ASP.NET MVC and Web API used to do (but not WCF Web API, AFAICT), so I guess it's one of those "by design" decisions.

Unfortunately, this behavior makes the routing stack pretty much inconsistent with the rest of ASP.NET Core, where path comparisons take the trailing slash into account (e.g all the security middleware).

Since changing this behavior at this point is very unlikely, would you consider adding new semantics to enable strict comparisons? E.g:

[HttpPost("~/path", StrictMatching = true)]
public IActionResult Test() => Empty();

[Eilon]

@PinpointTownes the reason right now is historical: ASP.NET's Routing always ignored trailing slashes. But then the historical reason is that we found for almost all cases where Routing is used, the difference is insignificant.

Having said that, I fully agree that the two URLs are different - then again, URLs that vary by case are different as well, yet Routing is case-insensitive. And then there's all the crazy path normalization stuff that various layers in the system perform, such as URL-decoding segments, collapsing multiple / into a single /, etc. You know, by the time the URL makes its way from the browser to the user's app code, it looks nothing alike! 😄

Ok, ok, ok, yes, the feature you suggest is reasonable. It's probably more specifically in this case something like MatchTrailingSlash = true or something because it isn't clear what "strict" means here.

[rynowak]

then again, URLs that vary by case are different as well, yet Routing is case-insensitive

IMO this is crazy. Yeah I know that I'm not helping 😆

=======

I'd personally love for us to morph routing into something that isn't just the strict set of compatibility requirements that MVC has always had.

[Eilon]

While we're at it, let's abolish the concept of casing in languages! What purpose does casing really serve??

[kevinchalet]

Sorry for the late reply 😅

Having said that, I fully agree that the two URLs are different - then again, URLs that vary by case are different as well, yet Routing is case-insensitive.

True, but the big "problem" with how trailing slashes are handled is that there's no consistency across the stack, which led to the bug reported in the SO question: PathString.Equals uses the case-insensitive ordinal comparer by default - which matches what Routing does - but considers /path and /path/ as different paths while Routing treats /path, /path/, /PATH and /PATH/ like identical route templates.

Actually, I guess the discussion shouldn't be limited to Routing, as it's a broader design decision, that would also impact HTTP abstractions primitives like PathString.

It's probably more specifically in this case something like MatchTrailingSlash = true or something because it isn't clear what "strict" means here.

Yeah, it's clearer (StrictMatching was generic enough to include both trailing slash and casing, but it's probably better to separate the two).

[Eilon]

@PinpointTownes yup, understood.

[rclabo]

The situation where /path and /path/ are considered the same by the Asp.Net Core route engine is also problematic from and SEO perspective. Google considers these two different end points (which of course they are) and if they return the same content Google will considers this a "Duplicate Content" issue and will reduced the ranking of these pages in the search results (which as you can imagine has financial consequences for companies).

If an attribute based route is specified as [Route("/example/")] then there needs to be some way to indicate that only /example/ should match it; Not /example and not /Example/ but only /example/ .

I can work around the case insensitivity issue by using middleware to force all paths to lower case by issuing a 301 redirect for non conforming paths to force them to be all lowercase. But I'm stumped on how to force /example to not match an attribute based route of [Route("/example/")]. Is there a workaround?

[Eilon]

@rclabo yup, that's something we'd want to consider here for sure.

[rclabo]

I wrote up the duplicate content issue and a workaround here: http://stackoverflow.com/questions/42929370/how-to-require-directory-trailing-slash-when-using-asp-net-core-attribute-based

[aspnet-hello]

This issue was moved to #2667

[rynowak]

I'm reopening this for consideration as part of the current routing work.