You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a methodn on Router that takes a function that receives the list, and returns a handler. This seems really intrusive, though, and largely duplicates existing functionality:
// CustomMethodNotAllowedHandler sets a custom MethodNotAllowed factory. Takes precidence over MethodNotAllowed if both are setfunc (mx*Mux) CustomMethodNotAllowedHandler(func(allowedMethods []string) http.HandlerFunc)
Re-calculate the list somehow. I don't see an efficient way to do this, but maybe I'm overlooking something.
As a last restort, I could potentially use a middeware that wraps the entire chi Mux, and detects the Allow: header to extract the values that way. Meh
The text was updated successfully, but these errors were encountered:
flimzy
added a commit
to flimzy/chi
that referenced
this issue
Dec 14, 2023
The default MethodNotAllowed handler uses
Context.methodsAllowed
to set the "Allow" header in the response.It would be nice to expose that list of allowed methods to a custom handler, as well.
Options I've considered:
Simply export that field of the
Context
struct. This would allow access when theContext
value is retrieved from ther.Context()
Add a function that extracts the unexported field from a context, and returns it. Something like:
Add a methodn on
Router
that takes a function that receives the list, and returns a handler. This seems really intrusive, though, and largely duplicates existing functionality:Re-calculate the list somehow. I don't see an efficient way to do this, but maybe I'm overlooking something.
As a last restort, I could potentially use a middeware that wraps the entire chi Mux, and detects the
Allow:
header to extract the values that way. MehThe text was updated successfully, but these errors were encountered: