Giters

prometheus / client_python

Prometheus instrumentation library for Python applications

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Network scanners report issues because all HTTP methods are supported

andy-maier opened this issue · comments

commented

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?

commented

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