Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Return custom status code #347

Closed
fk1blow opened this issue Sep 7, 2016 · 4 comments
Closed

Return custom status code #347

fk1blow opened this issue Sep 7, 2016 · 4 comments

Comments

@fk1blow
Copy link

fk1blow commented Sep 7, 2016 •
edited

We have a single page app that connects to an api which may or may not respond, eg: could be down, the request object may be invalid, connectivity issues, etc. and we'd like to respond with a proper response code for those cases(4xx, 5xx) and not just a 200 and a page with important notifications/warning.

I think, this problem is very similar to window.prerenderReady, where the spa "notifies"
the prerender server that the page is ready to be rendered.

At this moment, i can see only 2 options:

  • modify prerender io internals to return a status code based on a window variable, similar
    to prerenderReady, adding the proper status code to the response returned by prerender
  • build a plugin that "reads" a specific window variable which returns the proper status code

I would very much like to use the second option but before jumping to various hacks and workarounds.

Thanks in advance!
@thoop
Copy link
Contributor

thoop commented Sep 7, 2016

We currently have the prerender-status-code meta tag to allow you to do this. Would that work? See the plugin here: https://github.com/prerender/prerender/blob/master/lib/plugins/httpHeaders.js

After a 4xx or 5xx response from your server, you would insert this meta tag into the <head> of your page:
<meta name="prerender-status-code" content="404">

The plugin I linked above looks for this meta tag after the page is done loading and then returns the status code found in the content property as the new status code.

@fk1blow
Copy link
Author

fk1blow commented Sep 8, 2016

thanks, thoop,
will try it out and come back with a result.

@fk1blow
Copy link
Author

fk1blow commented Sep 12, 2016 •
edited

ok, this plugin works but with a slight problem(huge one, imho).
At the first hit, if i add a "prerender-status-code" meta, the status code inserted as the "content" attribute, makes prerender return that specific status code. One a second hit, the page is being fetched from the disk(we use the 'prerender-filesystem-cache' middleware) but now the status code returned is 200.
I think this happens because the prerender-status-code middleware is being bypassed, somehow(haven't looked at the flow, it's just my presumption).

Update
I've just read through the prerender filesystem cache plugin, and it seems it doesn't call a next() which, as i understand it, calls the next middleware in the chain.

    this.cache.get(req.prerender.url, function (err, result) {
      if (!err && result) {
        console.info('cache hit for: '+req.prerender.url);
        req.prerender.fileSystemCached = true;
        res.send(200, result);
      }
      else {
        return next();
      }
    });

The reason for reporting the finding here is that the plugin above has disabled the "Issues" section.

@thoop
Copy link
Contributor

thoop commented Sep 12, 2016

calling res.send with the result is fine. You don't want it to continue on and render the page again. You want it to end there while returning the cached page.

It looks like the real issue is this line isn't checking for a status code. They are always just saving to the cache, no matter the status code. That's bad.

Feel free to fork their code, check the status code, and send them a pull request!

@thoop thoop closed this as completed Sep 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@fk1blow @thoop