Handle 404 better #1596
Handle 404 better #1596
Conversation
This is potentially a breaking change for anyone who has not made their client-side routes accessible on the server, because the response will always be 404 for client side routes. The site will still render, but search engines will not index any routes.
This will ensure the 404 status code is replaced with the correct 200 code
…ispatch the route
Adds a snippet to demonstrate using custom template for 404s
Adds a snippet to demonstrate using custom template for 404s
Handle 404s correctly (Fixes #1055)
|
I tried both a fresh app (Meteor 1.6) and an existing app (1.5.2.2), both working properly with the package on this branch.
Is there anything specific required to replicate your case? |
|
@marxo ah, it's happening for me when the route is declared only on the client that means there's potentially a significant behavior change here, since we don't explicitly require that all routes be declared in a shared space (https://github.com/iron-meteor/iron-router#routes-on-client-and-server) |
|
@chrisbutler Yep, now I see it. Should |
|
@chrisbutler I'm looking at the middleware stack and as far as I can see when I move the route file to _handlersForEnv: { client: false, server: false }in the dispatch call. However, when I move it to the shared space, I get _handlersForEnv: { client: true, server: false }for client routes. Could this be a bug with the middleware stack? If I move the route definition to the |
@marxo i reverted the devel branch, we can track this here and I can merge if/when there's a working solution