-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
RFC: Return an instance of *fiber.Error
when no handler found
#1847
Conversation
When a handler cannot be found for a given path, previously Fiber would construct a plaintext response that cannot be modified. This commit switches to returning a new instance of `*fiber.Error` with identical error message so that users can customise the look of their 404 pages. Signed-off-by: AKP <[email protected]>
It appears that the
// what's in the test
app.Use(func(c *Ctx) error {
utils.AssertEqual(t, MethodGet, c.Method())
c.Next()
utils.AssertEqual(t, MethodGet, c.Method())
return
})
// changing the test to this makes the test pass
app.Use(func(c *Ctx) error {
utils.AssertEqual(t, MethodGet, c.Method())
err := c.Next()
utils.AssertEqual(t, MethodGet, c.Method())
return err
}) The
// what was in the test:
expected := fmt.Sprintf("%dHost=example.comhttp0.0.0.0example.com/?foo=bar/%s%s%s%s%s%s%s%s%s-", os.Getpid(), cBlack, cRed, cGreen, cYellow, cBlue, cMagenta, cCyan, cWhite, cReset)
utils.AssertEqual(t, expected, buf.String())
// changing to this makes the test pass
expected := fmt.Sprintf("%dHost=example.comhttp0.0.0.0example.com/?foo=bar/%s%s%s%s%s%s%s%s%sCannot GET /", os.Getpid(), cBlack, cRed, cGreen, cYellow, cBlue, cMagenta, cCyan, cWhite, cReset)
utils.AssertEqual(t, expected, buf.String()) |
This test was failing as the error returned by `c.Next()` that's required to generate the correct 404 status code was not being passed through the middleware and being silently ignored. Signed-off-by: AKP <[email protected]>
Signed-off-by: AKP <[email protected]>
I am unsure as to what to do with the failing |
As far as I can tell, this test is meant to check that a cached HEAD request to a given endpoint does not return the cached content to a GET request to the same endpoint, and the test has been altered to correctly check for this. Signed-off-by: AKP <[email protected]>
As far as I can tell, If this assumption is incorrect, please let me know. |
@ReneWerner87 If you're happy with this, I'm ok for it to be merged. |
For me it would be okay, just want to ask the other maintainers for their opinion In the next release it will be then in any case. |
Update docs as per gofiber/fiber#1847
…ber#1847) * Return an instance of `*fiber.Error` when no handler found When a handler cannot be found for a given path, previously Fiber would construct a plaintext response that cannot be modified. This commit switches to returning a new instance of `*fiber.Error` with identical error message so that users can customise the look of their 404 pages. Signed-off-by: AKP <[email protected]> * Fix `Test_App_Next_Method` This test was failing as the error returned by `c.Next()` that's required to generate the correct 404 status code was not being passed through the middleware and being silently ignored. Signed-off-by: AKP <[email protected]> * Fix `Test_Logger_All` Signed-off-by: AKP <[email protected]> * Fix `Test_Cache_WithHeadThenGet` test As far as I can tell, this test is meant to check that a cached HEAD request to a given endpoint does not return the cached content to a GET request to the same endpoint, and the test has been altered to correctly check for this. Signed-off-by: AKP <[email protected]>
What does this change?
This pull request alters the routing behaviour of Fiber to return an instance of
*fiber.Error
when a handler cannot be found to service a given request. Prior to this commit, Fiber formed a plain-text response on-the-fly that cannot be modified by users of the framework.This change means that errors resulting from no matching handlers being found would be routed via
fiber.App.config.ErrorHandler
, just like other errors are within Fiber.Why might we want this change?
This change allows users to customise the look of their 404 page, for example, to serve a proper HTML page instead of serving plain-text.
Additionally, this would remove the need to add a custom 404 handler to the end of the call stack as documented here, which prevents
405 Method Not Allowed
responses from here being correctly served. This is due to the 404 handler matching every request that otherwise exhausts the list of currently registered handlers. By switching to returning an error instead of making an on-the-fly response, we remove the need for the catch-all 404 handler to exist, hence meaning405 Method Not Allowed
responses will be dealt with correctly.Precedent
Returning
*fiber.Error
types to form an appropriate error response is already done in the codebase, for example when serving405 Method Not Allowed
responses.Considerations
Could this count as a breaking change? Theorietically, any user using the framework should already have an adequate error handler in place. If they chose to continue using the default error handler, nothing would appear to change - responses generated by this change and by the previous code are identical when using the default error handler.
It is not impossible to think that this could be a breaking change, as the
fiber.App.config.ErrorHandler
function is now being called with errors that it was not once called with. However, I believe that this change should not cause an issue as it is assumed that any user of the framework has a functional error handler already impemented, be it the default one or a custom one.This error cannot be checked for using
errors.Is
. Instead, you'd have to do something like this:I'd be interested to hear everyone's opinions and feedback on this proposal.
:)