-
-
Notifications
You must be signed in to change notification settings - Fork 980
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
Ambiguities re middlewares after routes #712
Comments
I need to add, about package main
import (
"fmt"
"net/http"
"github.com/go-chi/chi/v5"
)
func main() {
router := chi.NewRouter()
router.Use(dummyMiddleware)
router.Group(func(subRouter chi.Router) {
fmt.Println("Middlewares of sub-router inside Router.Group():", subRouter.Middlewares())
subRouter.Get("/foo", func(w http.ResponseWriter, r *http.Request) {
_, _ = w.Write([]byte("foo"))
})
})
panic(http.ListenAndServe(":8080", router).Error())
}
func dummyMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
fmt.Println("dummyMiddleware!")
next.ServeHTTP(w, r)
})
} Run this, query Is this intentional? If so, does this mean that the sub-router gets the stack of middlewares of the parent router but its additions do not propagate to the latter? If this is the case, this means that you cannot use |
this is all intentionally yes. nothing we can do about it. sorry for the confusion, but this is how it is. the .Group() is a helper for inline-middleware handlers. Feel free to read the code to see find the answers why the design is constrained this way. |
it provides with a copy of parent middleware stack, on top of which you can apply middleware specific to the group only @pkieltyka perhaps the godoc might be a bit misleading?
|
Yep, as I said, that at least could do with some clarification. |
@curio77 would you be able to improve the godoc for the |
Yep, will do… |
I'd like to add that it feels kinda weird to document such intrinsics/caveats on an interface method. Don't know whether it's actually just intrinsics of the implementation in |
In the following example,
Why does the line marked
// XXX
raisepanic: chi: all middlewares must be defined before routes on a mux
? (Please ignore the pointlessness of the specific middlewares in this scenario, just adding any for testing purposes.)Routes have been defined in sub-muxes via
Router.Group()
, but this apparently still prevents the later application of middlewares at the level of the parent/top router, despite the sub-muxes getting “fresh” middleware stacks as per the docs.If the interpretation is that the sub-mux's route definitions count as route definitions per se, then why doesn't the second
Router.Group()
call panic for the same reason? Conversely, does theRouter.Use()
call marked// XXX
apply its middleware to the sub-muxes as well?The text was updated successfully, but these errors were encountered: