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

No Placeholders in Active Health Checking Headers #5686

Closed
PoneyClairDeLune opened this issue Aug 4, 2023 · 3 comments · Fixed by #5861
Closed

No Placeholders in Active Health Checking Headers #5686

PoneyClairDeLune opened this issue Aug 4, 2023 · 3 comments · Fixed by #5861
Labels
feature ⚙️ New feature or request
Milestone

Comments

@PoneyClairDeLune
Copy link

PoneyClairDeLune commented Aug 4, 2023

Version

Caddy: 2.7.2

Bug description

When defining a header in the active health checker, placeholders as header values do not get interpreted altogether.

Expected behaviour

Placeholders set in active health checker headers should be interpreted normally as everywhere else in the Caddyfile.

Steps of bug reproduction

  1. Set a new web server for request catching. This can either be a Caddy server, or any new web server spun up with any language.
    Example Caddyfile snippet and WingBlade (JavaScript) web server snippet below.
http://127.0.0.1:8081 {
	log {
		level INFO
	}
	handle /api/example {
		respond "OK"
	}
}
"use strict";

WingBlade.web.serve(async function (request) {
	console.info("New request received. Header info below.");
	request.headers.forEach((value, key) => {
		console.info(`${key}: ${value}`);
	});
	return new Response("OK", {
		status: 200
	});
});
  1. Set a header in a new reverse proxied target with an active health checker. Example Caddyfile snippet:
...
health_uri "/api/example"
health_headers {
	X-Hostname "{system.hostname}"
}
...
  1. Reload the Caddyfile.
  2. Check the sent headers in the target. Prettified Caddy log entry and WingBlade service log outputs are below.
{
	"level": "info",
	"ts": 1691110717.1085844,
	"logger": "http.log.access",
	"msg": "handled request",
	"request": {
		"remote_ip": "127.0.0.1",
		"remote_port": "41368",
		"client_ip": "127.0.0.1",
		"proto": "HTTP/1.1",
		"method": "GET",
		"host": "127.0.0.1:8081",
		"uri": "/api/example",
		"headers": {
			"User-Agent": ["Go-http-client/1.1"],
			"X-Hostname": ["{system.hostname}"],
			"Accept-Encoding": ["gzip"]
		}
	},
	"bytes_read": 0,
	"user_id": "",
	"duration": 0.003900064,
	"size": 2,
	"status": 200,
	"resp_headers": {
		"Server": ["Caddy"],
		"Content-Type": ["text/plain; charset=utf-8"]
	}
}
New request received. Header info below.
User-Agent: Go-http-client/1.1
X-Hostname: {system.hostname}
Accept-Encoding: gzip
@mholt
Copy link
Member

mholt commented Aug 4, 2023

I guess we didn't enable placeholders there because most placeholders are only available in the context of an HTTP request, which active health checks aren't. But the system and env var placeholders are always available, so that'd make sense.

After 2.7.3 I can add support for this. But not before 😅

@mholt mholt added the feature ⚙️ New feature or request label Aug 4, 2023
@mholt mholt modified the milestones: v2.7.4, 2.9.0 Aug 4, 2023
@francislavoie
Copy link
Member

Implemented in #5861, if you'd like to try it out!

@PoneyClairDeLune
Copy link
Author

@francislavoie tysm! It's now working correctly.

New request received. Header info below.
accept-encoding: gzip
host: 127.0.0.1:8000
user-agent: Go-http-client/1.1
x-hostname: testenv

@francislavoie francislavoie modified the milestones: v2.9.0, v2.8.0 Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature ⚙️ New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants