Allow header is missing from 405 response

[ibnesayeed]

When a resource returns 405 Method Not Allowed response, it does not include an Allow header to tell the client what methods are allowed for the resource. According to the RFC7231 this header is a MUST in case of a 405 response.

   The 405 (Method Not Allowed) status code indicates that the method
   received in the request-line is known by the origin server but not
   supported by the target resource.  The origin server MUST generate an
   Allow header field in a 405 response containing a list of the target
   resource's currently supported methods.

For example, when interacting with the newly added webhook (#1663) feature using a POST method, things works as expected:

$ curl -X POST -i https://portainer.example.com/api/webhooks/<token>
HTTP/1.1 204 No Content
Date: Sat, 01 Sep 2018 18:09:34 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block

When the same resource is accessed using GET method, the response does not include an Allow header:

$ curl -i https://portainer.example.com/api/webhooks/<token>
HTTP/1.1 405 Method Not Allowed
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Sat, 01 Sep 2018 18:30:40 GMT

Even when the capabilities of the resource are queried explicitly using OPTIONS method, the response remains similar:

$ curl -i -X OPTIONS https://portainer.example.com/api/webhooks/<token>
HTTP/1.1 405 Method Not Allowed
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Sat, 01 Sep 2018 18:35:20 GMT

The response should be something like this:

$ curl -i https://portainer.example.com/api/webhooks/<token>
HTTP/1.1 405 Method Not Allowed
Allow: POST
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Sat, 01 Sep 2018 18:30:40 GMT

I am not sure if this issue is limited to just the webhooks or affects the whole HTTP API of the application.