Support for 405 Method Not Allowed

[martensson]

Would be great to easy add support for status 405, specially when creating a REST API.

And do you have any example adding a more verbose access logger? Logging response-code, user-agent, client-ip, etc?

Keep up the good work! 👍

[manucorporat]

What kind of support would you like? Right you could call:

func(c *gin.Context) {
    c.String(405, "method not allowed")
    // or even better: c.Fail(405, "method not allowed")
    // or both! ha
}

We are already working to improve logging possibilities, check this out: #16
but we wanted to implement it properly, that's why it is not in this release.

[martensson]

Thanks a lot Manu!

But lets say I have:

v1.GET("/services", func(c *gin.Context) {
    // do something
    c.JSON(200, something)
})

How do I implement so all other methods to /services except GET responds with 405?

And great to see that you are improving the logging possibilities :)

[manucorporat]

I guess it's a little bit hacky, but you can use:

    router.NotFound404(func(c *gin.Context) {
        if c.Req.RequestURI == "/services" {
            c.String(405, "Method Not Allowed")
        }
    })

Definitely, now I want to include good support for 405, but since it's a routing issue, I am going to ask the maintainer of HttpRouter.

It will print: "http: multiple response.WriteHeader calls"
do not worry about that, it's not an important issue and we are about to fix that: #16

[martensson]

Muchas Gracias Manu!

Its true it looks like a bit evil hack for now, and hopefully there will later on be greater support. 👍

Looking forward to see how Gin develops :)

[bobthecow]

See julienschmidt/httprouter#13

[bobthecow]

@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?

[bobthecow]

[javierprovecho]

Sorry for delay. Support for HTTP 405 has been added julienschmidt/httprouter#51 . Closing this issue now.