Setting headers for http checks

[majormoses]

I dont see anything in the docs, is there any way to set a header for an http consul service check? I would imagine it useful for people to set headers such as 'X-Forwarded-Proto: https' on a check

[slackpad]

There currently isn't any support for controlling the headers of the HTTP check, marking as an enhancement.

[scalp42]

Tweaking the user agent comes to mind as well.

[ryanbreen]

IMHO, adding this feels like a slippery slope. I like the current balance where simple HTTP calls work fine as http checks and more complicated things can be accomplished through script checks. I would hate for us to turn Consul's http check into curl.

[slackpad]

That's a good point @ryanbreen - even headers brings to mind complexity around supporting multiple, etc. I'll change this to thinking for now, because we don't want to introduce a bunch of complexity. If there are a few extra options that are highly useful, it might make for a better experience, but we don't want a curl-level of stuff for sure.

[majormoses]

I can definitely see how this could get out of hand quickly...I think a few options that would cover 90% of the use case would be great. Otherwise you are going to end up with a lot of people resorting to cmd script just to run a curl just to change something like the protocol to https, etc. I will keep thinking about this...see if I can think of some middle ground

[tdooner]

Just found this issue after wanting to do this. My use case: I have an nginx instance with multiple virtual hosts and I'd like to health check their instances separately. RIght now I'm forced to use the command health check, e.g.:

curl --fail --silent -H"Host: foo.example.com" http://localhost

It'd be great to not have to shell out in order to accomplish this relatively-basic functionality. It doesn't really feel like a slippery slope to me to allow arbitrary HTTP headers -- just looping through some object and calling req.Header.Set here.

Being able to replicate cURL's --insecure flag would be great too, but I understand the point about not reinventing the wheel as much as possible.

[truszkowski]

Is possible to send header "Accept: /" (by default)?
This header is needed by RFC... and go-restful for example (406 response).

[slackpad]

Hi @truszkowski this was added in #1819 which will be going out in today's release of Consul 0.6.4.

[slackpad]

Headers seem pretty reasonable to support and there have been several requests.

[klynch]

Setting the Host header would be extremely useful for us as well.

[ashald]

We have the same requirement - we need to set host header. I can contribute the PR adding the option if it will help (my last PR didn't get much attention so checking in advance).
If you OK with a PR then would you like an option headers taking a dictionary with headers?

[slackpad]

Hi @ashald we'd take a PR for this - thank you!

[ihr]

This feature would be very helpful in use cases of PaaS, such as with Cloud Foundry which allows you to identify unique app instance with the inclusion of a X-Cf-App-Instance header

[tgs]

Since the Host header isn't set, we have to turn off an important security setting of our apps. For example, for a Django app, we have to set ALLOWED_HOSTS = ['*']. This is a security problem because of DNS rebinding attacks, where an attacker circumvents the Same Origin Policy by making a browser think that your server is part of their origin, for example banking.attacker.com instead of banking.com. This enables cross-site scripting, so malicious javascript can perform any actions made available in the web application. The usual solution to this class of attacks is to have the web application check the Host header of incoming requests. If the browser is accessing the app as banking.attacker.com instead of banking.com, the app notices and ignores the request. However, to make our apps pass health checks, we have to disable this check.

[slackpad]

Fixed via #3107.

[ashald]

@slackpad 👍 👍 👍