@manucorporat Given httprouter's response to the original request, it seems like this should be handled at the Gin end.

I wrote a middleware adding support for 405 Method Not Allowed (with the appropriate "Accept" header and everything). It intercepts 404 responses and intelligently converts them to 405s if applicable. In order to shoehorn this into contrib, it would require exposing httprouter or passing through its Router Lookup method.

// Pass through httprouter Lookup.
// Lookup allows the manual lookup of a method + path combo, for more powerful middleware and such.
func (engine *Engine) Lookup(method, path string) (httprouter.Handle, httprouter.Params, bool) {
    return engine.router.Lookup(method, path)
}

The middleware could also go into Gin itself rather than contrib, and Gin's httprouter instance could be directly injected into the middleware on initialization. This would make it so only Gin could add the middleware, though, so it would be an Engine option rather than a composable middleware... kind of like the "trailing slash redirect" option in httprouter. I'd lean more toward this approach, and even enable it by default, but I'm not sure if that's in line with Gin's philosophy.

So where should I send the pull request? One to contrib with the middleware plus one to gin exposing httprouter Lookup, or just one pull request to Gin with the more integrated approach?

Support for 405 Method Not Allowed #20

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions