Using a parameter on the root with iron-router - meteor

I'm wondering how iron-router handles using a parameter on the root.
Say I've got a handful of routes:
Router.route("/:uri"); // domain.tld/MyCustomUri
Router.route("/app/login"); // domain.tld/app/login
Router.route("/about"); // domain.tld/about
This works, but I'm wondering how iron-router parses it, and if there are any efficiency issues?
In this case is iron-router checking to see if the parameter on the root matches a route case, if not then it must be a :uri parameter (and therefore settles on that), or is it just hitting the routes in chronological order? What's the logic iron-router is using here?

According to this tutorial from Manuel Schoebel:
The routes are checked in the order you created them.
Therefore in your case, /about would point to your /:uri route, with this.params.uri == "about". (and your /about route could not be reached)
I thought I also read this rule in the official documentation as well but sadly, I cannot seem to find it back. You can find comments that support this premise though.
People are discussing in an open issue on the project's Github of the possibility to allow iron-router to "be smart" and match "static routes" in priority to ones with parameters, regardless of the order the routes were declared in. So I am guessing it is not the case as of today.

Related

HERE API Calculate Route - avoid anything changes router behavior

Problem
If you choose to use avoidArea, exclueCountries or avoidLinks (and probably some more that I wasn't able to test) in your request router enforces fastest route mode.
Given is route from Poland to Germany.
Official testing client: http://refclient.ext.here.com/
First request (no avoids, no excludes, mode:shortest) was:
https://route.api.here.com/routing/7.2/calculateroute.json?app_code=pxIXqdtgOSwQDXSDfjLQpw&app_id=cgZPrYfgRePXzXC3PbBp&jsonattributes=41&language=en-us&legattributes=le&maneuverattributes=po,ti,pt,ac,di,fj,ix&metricsystem=metric&mode=shortest;car&routeattributes=sh&waypoint0=geo!stopOver!53.49012,18.80973&waypoint1=geo!stopOver!53.61957,12.43167
This resulted in a quite straightforward route like below.
If we add now any country exclusion (e.g. GBR, CHE, CZE) the route is now routed via motorways like fastest mode was enforced.
https://route.api.here.com/routing/7.2/calculateroute.json?app_code=pxIXqdtgOSwQDXSDfjLQpw&app_id=cgZPrYfgRePXzXC3PbBp&avoidseasonalclosures=false&excludecountries=CHE,GBR,CZE&jsonattributes=41&language=pl-pl&legattributes=le&maneuverattributes=po,ti,pt,ac,di,fj,ix&metricsystem=metric&mode=shortest;car&routeattributes=sh,zo&waypoint0=geo!stopOver!53.49012,18.80973&waypoint1=geo!stopOver!53.61957,12.43167
EDIT 1 BEGIN
I checked out the new routing API and results are similar:
Without avoids:
https://route.ls.hereapi.com/routing/7.2/calculateroute.json?apiKey={API_KEY}=41&language=en-us&legattributes=le&maneuverattributes=po,ti,pt,ac,di,fj,ix&metricsystem=metric&mode=shortest;car&routeattributes=sh&waypoint0=geo!stopOver!53.49012,18.80973&waypoint1=geo!stopOver!53.61957,12.43167
With avoids:
https://route.ls.hereapi.com/routing/7.2/calculateroute.json?apiKey={API_KEY}&avoidseasonalclosures=false&excludecountries=CHE,GBR,CZE&jsonattributes=41&language=pl-pl&legattributes=le&maneuverattributes=po,ti,pt,ac,di,fj,ix&metricsystem=metric&mode=shortest;car&routeattributes=sh,zo&waypoint0=geo!stopOver!53.49012,18.80973&waypoint1=geo!stopOver!53.61957,12.43167
On a sidenote, http://refclient.ext.here.com/ doesn't have option to test new API
EDIT 1 END
Question
Why is it happening? Is it designed behavior? If not, when can we expect this to be fixed?
Ok, I've got an answer for you from engineering. I'm rewording a bit so any mistakes/confusion blame me, not him. :)
So yes, the API here is ignoring your request to use shortest.
Quote from developer: Specifically in this case, when using "shortest" mode and requesting additional "avoids", routes more than 300km or so are not "good". It does not fall back to "fastest" mode but another mode where "fastest" route shape has more of an influence.
You mentioned wanting to avoid tolls, be aware that you can ask for that option when calling the API, so that may be a solution for you.
I hope this helps a bit, and thank you for being patient.

Extending ASP.NET MVC 4 MvcHandler

I'm trying to add some functionality to the default MvcHandler. What's happening is: I wanted to have dashed url's instead of Pascal Case url's. In other words if my controller is SomeController I wanted the URL to be /some-controller instead of /SomeController.
My best workaround was: I've created one mapping file URLMappings.xml which maps each controller to each desired URL. Then I've extended the default Route class to generate outgoing url's based on this and the default RouteHandler to understand the url's based on this. Well, this works fine because even if some mapping wasn't created then the framework will use the default behavior.
My point is: with this the routing system was understanding both kinds of Url's and this leads to duplicate content SEO problem. I wanted then to implement the following:
Get the controller value
See if on some mapping the controller name matches the value
If it matches, then there's some preferable URL than the one that was typed, should return 404.
I've searched on the web and the only way I've found to do this was to create a new IHttpHandler. However I don't want one from scratch, since I need all MVC functionality. I just want to put this logic on the ProcessRequest, however my overidden version of the method is not being executed.
Can someone give me some idea on how to deal with this ? Sorry if the question is silly or if it's not well detailed. If there's need for more information, just tell me.
You don't need a custom MvcHandler but a custom Route. There's a already NuGet package for this functionality called LowercaseRoutesMVC. Feel free to download it, explore the source code and adapt if necessary (to put the dash wherever you want to put it).

Force case-sensitive routing in ASP.NET MVC

This question has been asked in a similar but not identical fashion (and not resolved to my satisfaction) previously on Stack Overflow and elsewhere.
Coming from a linux-world, I want to use ASP.NET MVC but avoid identical but differently-cased routes from resolving to the same page. I do not want to force all routes to be 100% lowercase.
e.g. I want /Home/Something to be a valid route and /Home/somethingElse to also be a valid route, but not /Home/something or /home/somethingelse, given two functions called Something and somethingElse in the HomeController.
I can't find any way of doing this from within the RegisterRoutes function, but maybe I'm missing something obvious? I can answer this easily enough by adding code to each Controller function, but I'm obviously trying to avoid doing that.
Optimally, the solution would involve catching all permutations of a particular route, then 301 redirecting any that do not exactly match the case of the controller's function.
I was unable to find any way of doing this after extensive searching. Basically, case-sensitivity and IIS/ASP.NET apparently do not go together.
We're now using a bit of a kludge to solve this. The code has been opensourced (MIT license) on github: NeoSmart Web Toolkit, in particular, this file containing the SEO redirect code.
Using it is easy enough: each GET method in the controller classes needs to add just this one line at the start:
Seo.SeoRedirect(this);
The SEO rewrite class automatically uses C# 5.0's Caller Info attributes to do the heavy lifting, making the code above strictly copy-and-paste.
Ideally, I would love to find a way to turn that line of code into an attribute. For instance, prefixing the controller methods with [CaseSensitive] would automatically have the same effect as writing in that line, but alas, I do not (yet) know how to do this.
I also can't find any way of figuring this out with the Routing class/structures. That's some opaque code!

Concrete 5 search results page url

Concrete 5 search results page url contains some parameters. how to remove that parameters and make the url user friendly
On an apache server I recommend you to use the mod_rewrite module to use the RewriteEngine.
With this module you can specify aliases for some internal URLs (of course with parameters as well). You can also use RegEx for this.
RewriteEngine on Wikipedia
mod_rewrite tutorial
Short answer: it's probably not worth the trouble.
Long answer...
I'm guessing you see three query parameters when using the search block:
query
search_paths[]
submit
The first parameter is required to make the searches work, but the other two can be dropped. When I build concrete5 themes, I usually "hard-code" the html for the search form, so that I can control which parameters are sent (basically, don't provide a "name" to the submit button, and don't include a "search_paths" hidden field).
The "query" parameter, though, is not going to be easy to get rid of. The problem is that for a search, you're supposed to have a parameter like that in the URL. You could work around this by using javascript -- when the search form is submitted, use some jquery to rewrite the request so it puts that parameter at the end of the URL (for example, http://example.com/search?query=test becomes http://example.com/search/test). Then, as #tuxtimo suggests, you add a rewrite rule to your .htaccess file to take that last piece of the URL and treat it as the ?query parameter that the system expects. But this won't work if the user doesn't have javascript enabled (and hence probably not for Googlebot either, which means that this won't really serve you any SEO purpose -- which I further imagine is the real reason you're asking this question to begin with).
Also, you will run into a lot of trouble if you ever add another page under the page that you show the search results on (because you have the rewrite rule that treats everything after the top-level search page path as a search parameter -- so you can never actually reach an address that exists below that path).
So I'd just make a nice clean search form that only sends the ?query parameter and leave it at that -- I don't think those are really that much less user-friendly than /search-term would be.

Compare URIs for a search bot?

For a search bot, I am working on a design to:
* compare URIs and
* determine which URIs are really the same page
Dealing with redirects and aliases:
Case 1: Redirects
Case 2: Aliases e.g. www
Case 3: URL parameters e.g. sukshma.net/node#parameter
I have two approaches I could follow, one approach is to explicitly check for redirects to catch case #1. Another approach is to "hard code" aliases such as www, works in Case #2. The second approach (hard-code) aliases is brittle. The URL specification for HTTP does not mention the use of www as an alias (RFC 2616)
I also intend to use the Canonical Meta-tag (HTTP/HTML), but if I understand it correctly - I cannot rely on the tag to be there in all cases.
Do share your own experience. Do you know of a reference white paper implementation for detecting duplicates in search bots?
Building your own web crawler is a lot of work. Consider checking out some of the open source spiders already available, like JSpider, OpenWebSpider or many others.
The first case would be solved by simply checking the HTTP status code.
For the 2nd and 3rd cases Wikipedia explains it very well: URL Normalization / Canonicalization.

Resources