Sink.redirect() with status codes like 404 or 503

Hello !

I’m a bit confused : I would like to redirect server-side when :

  • there’s a 404 error
  • or a custom maintenance mode is activated. (503 status)

It appears that sink.redirect("/fallback", 503) or sink.redirect("/fallback", 404) does not redirect url, but it only modifies Location header and status code of response

BUT, if i’m just doing sink.redirect("/fallback", 302), it works fine, and URL is actually changed on client side.

Is it an issue, or am I missing something in the way meteor defines what can be considered as a redirect, and what can not ?

I would understand that 4XX & 5XX cannot be considered as valid status codes for redirection, but maybe an update of this method’s documentation or parameters control would make things clearer for anybody who would try to do the same. I’ll push a request if you think it makes sense. Bye !


How to reproduce easily ?

In a minimal project
meteor create --minimal test-redirect

change server/main.js :

import { Meteor } from "meteor/meteor";
import { onPageLoad } from "meteor/server-render";

Meteor.startup(() => {
  // Code to run on server startup.
  console.log(`Greetings from ${module.id}!`);
});

onPageLoad((sink) => {
  sink.redirect("/fallback", 302); // ---> works
  // sink.redirect("/fallback", 404); // ---> doesn't work as i'm expecting
  // sink.redirect("/fallback", 503); // ---> doesn't work as i'm expecting

  // Code to run on every request.
  sink.renderIntoElementById(
    "server-render-target",
    `Server time: ${new Date()}`
  );
});


Thanks for your help !

Meteor only sets the response headers and codes. The client is the one deciding what to do with those response headers.

I support changing the documentation. Linking here can help: Redirections in HTTP - HTTP | MDN

Thanks RJ,
So after your answer i’ve reconsidered my needs.

Actually, I won’t redirect 4xx & 5xx errors, but keep it and overwrite page content with proper indications of server status.

I’ll create a PR to update docs with the link you shared. I think, adding an invariant in order to restrict this function usage to certain statuses would be a good thing as well, but maybe too opinionated …