dotvvm
dotvvm copied to clipboard
Space at the end of route
When route url ends with space, routing cannot find the route. In this case, I think we should trim the routes url.
example:
config.RouteTable.Add("CustomerDetail", "page/detail ", "Views/customerDetail.dothtml");
this route is not match with "http://localhost:123/page/detail " even "http://localhost:123/page/detail%20" does not work.
@exyi @tomasherceg What do you think?
I don't think that trimming whitespace characters is a good idea, as it's "strange" behavior, that may be pretty unexpected. I'd rather validate the used characters in the URL according to https://tools.ietf.org/html/rfc3986#section-2 when the route matcher is initialized, and throw an exception. The set of allowed characters (including reserved) seems to be:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=`
Edit: plus the %
which has a bit special meaning, but is allowed.
I'm unlabeling this as a bug, as it's definitely not a bug, it's a proposal for validating route patterns.
Agree with @exyi - this is not a bug. But I don't know if validation of URL is a good idea - also, the %
sign is missing in the listing of allowed characters, and we also need {}
to represent parameters...
This would not be so easy to implement and I don't see huge benefit there.
This is clearly a mistake of the developer using the framework. If he tries to open a file on a path which has an extra space at the end, he will also get FileNotFoundException - .NET doesn't try to fix his mistakes and I think we shouldn't too.
Good point, I missed the %
, but it's described in the 2.1 section of the RFC. The {}
should be stipped by the "parser" that generates the match info. If we want to validate the URL we should definitely do it on the parsed data. The point in validating this is that this mistake seems to be pretty hard to find in comparison with the FileNotFoundException.
I think we should check how ASP.NET MVC routing behaves in this case.
I have tries what MVC does in this case, and it automatically escapes the space at the end of the route to %20
. Which means that it will be the same hard to debug what is wrong with the route.