Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add HTTP headers support to common HTTP client. #416

Merged
merged 1 commit into from Apr 29, 2024

Conversation

roidelapluie
Copy link
Member

This is named http_headers so it does not clash with blackbox exporter's headers and Prometheus remote client's headers, which are simple maps.

Signed-off-by: Julien Pivotto roidelapluie@o11y.eu

@roidelapluie
Copy link
Member Author

@jeromeinsf
Copy link

jeromeinsf commented Dec 7, 2022

Wondering if this will enable what was intended in #326

config/headers.go Outdated Show resolved Hide resolved
Comment on lines 53 to 55
Headers map[string][]string `yaml:"headers,omitempty" json:"headers,omitempty"`
SecretHeaders map[string][]Secret `yaml:"secret_headers,omitempty" json:"secret_headers,omitempty"`
Files map[string][]string `yaml:"files,omitempty" json:"files,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find this entire scheme a bit confusing, both in the non-uniformity of the names (we have normal headers, secret headers, and then just files, which I understand why can't be file headers but still), and also in the names themselves (secret headers could be interpreted as intended, a header with a secret value, or some sort of a "secret" header). Of course they'll be docs to clear this up but I still think it's less than ideal. Therefore, I propose we instead have an iterated:

type header struct {
  name/key string
  value string
  secret secret
  file string
}

Which I think would be more clear and also allow for more complicated header appends. Generally a small difference though so feel free to ignore.

Comment on lines 94 to 96
if _, ok := reservedHeaders[http.CanonicalHeaderKey(k)]; ok {
return fmt.Errorf("setting header %q is not allowed", http.CanonicalHeaderKey(k))
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would make more sense for this check to come first

@zetaab
Copy link

zetaab commented Dec 30, 2023

@roidelapluie @LeviHarrison what is status in this PR? At least I am interested of this feature

@Dronec
Copy link

Dronec commented Apr 10, 2024

Me too! Adding headers to requests is a relatively trivial operation and multiple APIs support that

@LeviHarrison
Copy link
Member

Just some small revisions

@roidelapluie friendly ping

This is named `http_headers` so it does not clash with blackbox
exporter's headers and Prometheus remote client's headers, which are
simple maps.

Signed-off-by: Julien Pivotto <roidelapluie@o11y.eu>
@roidelapluie
Copy link
Member Author

@LeviHarrison here you go 🙂

Copy link
Member

@LeviHarrison LeviHarrison left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks

As usual we'll need to update Prom docs after this

@roidelapluie roidelapluie merged commit 36303a8 into prometheus:main Apr 29, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants