Network scanners report issues because all HTTP methods are supported

[andy-maier]

A Prometheus exporter implemented with the prometheus_client package will respond to all HTTP methods, even though it is supposed to succeed only on GET /metrics. This behavior may be reported by network scanners as an issue.

Actual and proposed behavior:

HTTP method	resource	actual behavior	proposed behavior
OPTIONS	/*	200 + metrics	200 + Allow: OPTIONS,GET, no body
HEAD	/metrics	200 + metrics	200, no body
GET	/metrics	200 + metrics	200 + metrics
OPTIONS	any other	200 + metrics	404, no body
HEAD	any other	200 + metrics	404, no body
GET	any other	200 + metrics	404, no body
POST	any	200 + metrics	405 + Allow: OPTIONS,GET, no body
PUT	any	200 + metrics	405 + Allow: OPTIONS,GET, no body
PATCH	any	200 + metrics	405 + Allow: OPTIONS,GET, no body
DELETE	any	200 + metrics	405 + Allow: OPTIONS,GET, no body
CONNECT	any	200 + metrics	405 + Allow: OPTIONS,GET, no body
TRACE	any	200 + metrics	405 + Allow: OPTIONS,GET, no body
any other	any	200 + metrics	501, no body

I am using prometheus_client.start_http_server() for this.

The proposed behavior is my interpretation of the rules in HTTP 1.1 as described in RFC7231.

The list of methods for which I propose to return 405 (as opposed to 501) is the standard list of methods described in RFC7231 plus PATCH (RFC5789). There are many more methods registered in the IANA HTTP method registry.

Reproduction:

• Start Prometheus exporter that uses prometheus_client.start_http_server()
• Issue against the IP/port of the exporter:

  curl -k -i -X <method> http://<ip>:<port>/<resource>
  

Unfortunately, the Prometheus exporter best practices at https://prometheus.io/docs/instrumenting/writing_exporters/ do not touch on this subject.

If there is a possibility to change the actual behavior already now, please let me know. For example, issue #927 describes a way to reconfigure WSGI w.r.t. the returned HTTP version. Maybe something like this exists for the HTTP method behavior, too?

[andy-maier]

I have tried to address this issue in PR #1019.