Handling 404's

[Lepozepo]

I'm loving 0.6.0, it's great! Is there any particular way to handle 404's and render a template? This is what I'm currently doing:

    this.route('*', {
//      template:"not_found",
        where:"server",
        load:function(){
            this.response.writeHead(404);
            this.response.end();
        }
    });

When I uncomment the template I still can't get anything to show but at least the headers are right. Is there any way to render a static template after the response?

[wbashir]

I thought with the new version, an explicit catch all route wasn't needed. @cmather ?

[Lepozepo]

I tested using notFoundTemplate:"not_found", but the head was still 200 after running this command on the terminal:

curl --head 'http://localhost:3000/idontexist'

[austinrivas]

@Lepozepo I am also having trouble with 404's

I have the notFound template defined in my iron-router config but it doesn't seem to make a difference, this also applies to the loading template.

@cmather to replicate this bug you can clone austinrivas.meteor.com on the iron-router branch at this commit

All of my iron-router configs can be found in app/controllers/lib/config.controller.coffee

To run the app just cd into app and run as usual

[Lepozepo]

As far as I understood about the way iron-router works with the notFoundTemplate key is that it depends on the data key to return true or false. If data returns false then notFound gets rendered. I don't know if doing that makes the header return the 404 though.

[austinrivas]

@Lepozepo I don't think that is correct. It is my understanding that if the data property is set to false then iron-router just uses the last data context passed to a controller, allowing you to pass contexts from one page to the next. Pretty awesome feature if you ask me.

iron-router readme covers this in the data section

[Lepozepo]

@austinrivas I didn't know that, that's pretty cool!

[cmather]

Hey guys, The way data works has been updated a bit and the README was a little behind. If you call Router.setData({.. some data context ..}), the data context has to be different from the existing data context in order to invalidate dependencies. It works similarly to Session.set('someKey', 'someValue'). If someValue is the same as last time, it doesn't actually set a new value and call the dep.changed() method.

On 404, remember this is happening client side. If you use curl you're making a request to the server. On the client (once the js has executed), if you run a route and the data function returns something falsy, and there is a notFoundTemplate defined, then it will get automatically rendered (on the client).

On the server, there is no default 404 behavior yet.

[Lepozepo]

Is there any way of making both the client and the server respond with the 404? Basically push a template client side but put the 404 headers server side? Or is that a conundrum?

[tmeasday]

It's a bit of a conundrum. The reason is that in case of 404, we need to call out to the server from the client in case the URL will be handled by a file in /public or some such. So if the server just 404-ed you'd get poor behaviour in the client.

I'm not sure there's a better solution to all this but this is what we are doing for now.

[Lepozepo]

Yeah, I figured. Do you think rendering a 404 template will have a negative impact on search engines? I have no clue but I would suspect crawlers prefer a 404 from the server to a 404 from a template right?

[tmeasday]

I guess a search engine isn't going even realise its a "404" on the client because it'll be served with a 200 header.

But hopefully there won't be too many broken incoming links to your app :)

[serkandurusoy]

I wonder what the latest status on this is. It is currently very easy to carry out an seo-attack on a meteor page by submitting non-existent links from that app on random places on the internet. Google will quickly crawl those links, parse the pages, think that the site has some kind of automated duplicate content on thousands of non-existent pages, and boom, ranks fall. Also, by way of submitting a large number of links and thus getting google to crawl them, we can create a virtual DOS attack by means of google spiders since they will visit back seeking for changes on those links while they would not have were them proper 404 errors.

[cmather]

Server side 404s handled much better in the refactor branch. If no route defined the server sends a 404. Feedback on the approach would be great. Go check out router_server

[andreimcristof]

Can you provide a working example of how to use router_server? I already use the notFoundTemplate option in Router.configure, however this should also correctly return 404 as described above by @serkandurusoy

Thank you,

[andreimcristof]

@cmather can you please explain what you mean by "router_server" ? Ive read the docs and they dont mention anything like this. I am interested in the 404 fix.

Thanks in advance!

[codingisacopingstrategy]

Server side 404s handled much better in the refactor branch. If no route defined the server sends a 404.

This is great. This doesn’t really address @serkandurusoy ’s concerns though.
Taking an example from the guide:

Router.route('/post/:_id', function () {
  this.render('Post', {
    data: function () {
      return Posts.findOne({_id: this.params._id});
    }
  });
});

Currently the client can request /post/whateveridisnotexisting
and this will return a 200—whereas this should be a 404.

I understand you would need to put this logic on the server then, but only for the initial page load…
Not sure if Meteor provides for a non-hacky way to make this happen?

Cheers,

[serkandurusoy]

That's right. For example http://demo2.telescopeapp.org/posts/should-return-404 or at least http://demo2.telescopeapp.org/posts/should-return-404?_escaped_fragment_= should return 404 whereas I'm getting 200.

A proper 404 is crucial for search engine optimization and returning 200's for non-existing pages has penalties in the form of duplicate content

So, the ability to return 404 on the server side on purpose, while good, is irrelevant in this case.

[jnkien]

Waiting so much the 404 status server side.
Meanwhile, I just define this for old routes:

Router.route('oldroute', {
path: '/oldroute',
where: "server",
action: function(){
this.response.writeHead(404, {'Content-Type': 'text/html'});
this.response.end();
}
});

This can handle the case when Google crawls old routes. However, a blank page is rendered...

[copleykj]

if you change route names, you might be better off with a 301 instead of a
404.. Just a thought

On Tue, Dec 9, 2014 at 1:09 PM, Jean-Noël KIEN notifications@github.com
wrote:

Waiting so much the 404 status server side.
Meanwhile, I just define this for old routes:

Router.route('oldroute', {
path: '/oldroute',
where: "server",
action: function(){
this.response.writeHead(404, {'Content-Type': 'text/html'});
this.response.end();
}
});

This can handle the case when Google crawls old routes. However, a blank
page is rendered...

—
Reply to this email directly or view it on GitHub
#237 (comment)
.