-
Notifications
You must be signed in to change notification settings - Fork 459
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.
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
Deprecate shipped 404 and 500 middlewares #359
Milestone
Comments
Burn them with fire. |
👍 |
Just waiting on dougwilson/nodejs-depd#17. |
jasisk
added a commit
that referenced
this issue
Apr 7, 2015
These middleware cause more problems than they solve. Because they're everywhere, I'd like to keep them in place for another major. The default express handler is sufficient in many cases. This is more a documentation issue than anything else (and one we've already addressed in the generator). Closes #359.
Closed by #361 |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A couple of middleware ship in the
kraken-js
package but are—otherwise—not configured or enabled by default. They are able to be added to a project that useskraken-js
by being required:These middleware are presently configured by default with the yeoman generator. However, it's been my experience that they cause more problems than they solve. Some of the problems we've seen involve assumptions based on xhr and not
content-type
, the assumption a rendering engine exists resulting in 404s turning into 500s, etc. Relying on the default handler that ships with express is sufficient while developing, while writing an appropriate handler for production (404, 5xx) should be standard practice.The text was updated successfully, but these errors were encountered: