Allow
header support in Router, MethodNotFoundHandler (405) and CORS middleware
#2039
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for
Allow
header toAllow
header lists all method types registered for given routed url path.Related RFCs:
Allow
RFC https://datatracker.ietf.org/doc/html/rfc7231#section-7.4.1 all 405 should haveAllow
header listing all methods that router has registered for given path.Allow
is optional but useful header to haveImplementation notes:
next(c)
and hope to meet our router optionshandler we probably not succeed because of different kinds of authentication middlewares (ala JWT or BasicAuth or KeyAuth) which check for stuff like that.Allow
value to contextecho.ContextKeyHeaderAllow
is because default 405 handler needs to be able to access that value and possibly CORS middleware is interested in that value. Asecho.MethodNotAllowedHandler
is part of public API we can not change how that method is created due backwards compatibility.optionsMethodHandler
is kept private as it is router specific implementation detail. If you want your own then you can add them withe.OPTIONS()
method for paths you choose.Using context values in Echo core is so far unprecedented and potentially controversial decision. I did not want to introduce new field into
echo.context
struct as it is quite specific case and I know that Go standard libraryhttp.Server
is usingcontext.Context
to add some info to each request context - so it is not so unheard of but probably should be avoided:See:
Let's have a discussion