#!/bin/sh
# Bereitschaft: antwortet die Admin-API?
#
# Caddy oeffnet seine Admin-API (Vorgabe localhost:2019) erst, wenn die
# Konfiguration geladen ist -- das ist mehr als "der Prozess laeuft". Gemessen
# 24.09.2026 an caddy 2.11.4 OHNE jede Site: "GET /config/" antwortet 200, und
# "GET /reverse_proxy/upstreams" ebenso. /config/ ist der schlankere Weg und
# braucht kein Wissen ueber die Konfiguration.
#
# Die Adresse kommt aus der Caddyfile, wenn sie dort steht (admin-Direktive),
# sonst gilt Caddys Vorgabe. Raten waere hier besonders schlecht: wer die
# Admin-API abschaltet ("admin off"), soll einen Dienst bekommen, der nie
# bereit meldet, und nicht einen, der auf einem fremden Port antwortet.

set -u

CONF=${CADDY_CONF:-/etc/caddy/Caddyfile}
ADMIN=''

if [ -r "$CONF" ]; then
    ADMIN=$(sed -n 's/^[[:space:]]*admin[[:space:]]\+\([^[:space:]{]*\).*/\1/p' "$CONF" 2>/dev/null | head -n1)
fi
case ${ADMIN:-} in
'off') exit 1 ;;   # bewusst abgeschaltet: dann ist Bereitschaft nicht messbar
'') ADMIN='localhost:2019' ;;
esac

command -v curl >/dev/null 2>&1 || exit 1

# Geprueft wird rc UND ein nichtleerer Rumpf: ein 200 mit leerem Rumpf waere ein
# antwortender Port ohne geladene Konfiguration, und das ist nicht Bereitschaft.
# Dieselbe Lehre wie bei "pdns_control rping", das mit 0 endet und nichts sagt.
body=$(curl -s -m 3 -w '\n%{http_code}' "http://${ADMIN}/config/" 2>/dev/null) || exit 1
code=${body##*
}
payload=${body%
*}
[ "$code" = 200 ] || exit 1
[ -n "$payload" ] || exit 1
exit 0
