Pass 404 errors to the browser instead of ignoring it

[henrist]

I have an application where I send the meta tag prerender-status-code with 404 value, so that the Prerender-service will generate a 404-response. Unfortunately when this was done, the response from Prerender was ignored, bypassing the Prerender-service and sending a 200-response with the default catch-all template instead of the 404.

I can't find a reliable way of determining if the 404 is because the Prerender-service was not found or from the prerender-status-code-field, so in worst case if the case the Prerender-url changes, it will pass the 404 for all pages.

But I guess this is less likely than the application sending 404, and that we can assume it's from the meta tag.

[jeroennoten]

Hmm.. I'm not sure if this is the right solution. Wouldn't it be better, in case of a 404, to redirect to the actual app's page or something like that? Then, when that page does indeed not exist, it will show the app's 404 page, and if the page does actually exists (404 because the prerender server is not available for example), then it will show that page (not prerendered, but I think it is better than a 404).

Let me know what you think. Nevertheless thanks for the PR.

[henrist]

I guess in many cases (at least in my case), Laravel don't know all the frontend routes, only the one it provides for API. And even if it would, I guess it would probably not check for model existence, but let the frontend check that with the API (and then generate a soft 404, which Prerender changes to a real 404).

I agree it's not the best solution. The Prerender-service should rather send some headers indicating if for example the status code is from the application or Prerender-service, so we don't have to "guess".

[thoop]

Returning the status code that Prerender.io returns is the correct solution and how all other middleware currently works.