From 2ccb39a69b410467297a4f8eb4ca6af9e2ac5138 Mon Sep 17 00:00:00 2001
From: opencode <opencode@dennyapp.de>
Date: Sat, 19 Sep 2026 16:04:32 +0200
Subject: [PATCH] fix: redirect plain-http desfoto.de to HTTPS with an own
 router

The running Traefik instance has no global entrypoint http->https
redirection even though /srv/stack/docker-compose.yml declares one, so
plain http://desfoto.de/ answered with Traefik's default 404 once the old
desfoto-redirect-http router was removed. Route desfoto.de through its own
http router (desfoto-http + desfoto-http-to-https, permanent redirect) via
the proven live Docker provider instead of restarting the shared proxy.
Document the live-config drift in docs/deployment.md.
---
 compose.vps.yml    | 17 ++++++++++++++---
 docs/deployment.md | 32 +++++++++++++++++++++++++++++---
 2 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/compose.vps.yml b/compose.vps.yml
index 76a482d..5ac6c12 100644
--- a/compose.vps.yml
+++ b/compose.vps.yml
@@ -21,9 +21,20 @@ services:
       traefik.http.routers.desfoto-www.middlewares: desfoto-canonical
       traefik.http.routers.desfoto-www.service: desfoto
 
-      # HTTP is already redirected to HTTPS by the global Traefik entrypoint
-      # redirection (see /srv/stack/docker-compose.yml); the ACME http-challenge
-      # is answered by Traefik itself before the redirect.
+      # HTTP -> HTTPS. The shared Traefik instance is running WITHOUT the
+      # global entrypoint redirection that /srv/stack/docker-compose.yml
+      # declares (live-config drift, documented in docs/deployment.md), so
+      # desfoto.de carries its own http router instead of relying on the
+      # proxy's global configuration. If that global redirect is ever enabled,
+      # this router simply becomes unreachable. The ACME http-challenge is
+      # answered by Traefik's internal acme-http router (maximum priority)
+      # before this redirect can apply.
+      traefik.http.routers.desfoto-http.rule: Host(`desfoto.de`) || Host(`www.desfoto.de`)
+      traefik.http.routers.desfoto-http.entrypoints: http
+      traefik.http.routers.desfoto-http.middlewares: desfoto-http-to-https
+      traefik.http.routers.desfoto-http.service: noop@internal
+      traefik.http.middlewares.desfoto-http-to-https.redirectscheme.scheme: https
+      traefik.http.middlewares.desfoto-http-to-https.redirectscheme.permanent: 'true'
       traefik.http.middlewares.desfoto-canonical.redirectregex.regex: ^https?://(?:www\.)?desfoto\.de/(.*)
       traefik.http.middlewares.desfoto-canonical.redirectregex.replacement: https://desfoto.de/$${1}
       traefik.http.middlewares.desfoto-canonical.redirectregex.permanent: 'true'
diff --git a/docs/deployment.md b/docs/deployment.md
index 637e644..3900d9a 100644
--- a/docs/deployment.md
+++ b/docs/deployment.md
@@ -70,9 +70,35 @@ Regel-Länge). Der Container wird also zuerst gesund geprüft, und erst danach w
 die alten Labels entfernt — der Übergang hat damit kein Fenster ohne Antwort.
 
 `www.desfoto.de` wird über die Middleware `desfoto-canonical` dauerhaft auf
-`https://desfoto.de/...` umgeschrieben. Für `http` greift die globale
-Entrypoint-Weiterleitung von Traefik auf `https`; die ACME-HTTP-01-Challenge
-beantwortet Traefik selbst, bevor diese Weiterleitung greift.
+`https://desfoto.de/...` umgeschrieben. Für `http` bringt die Anwendung einen
+eigenen Router (`desfoto-http` + `desfoto-http-to-https`) mit, der dauerhaft
+(301) auf `https` umleitet. Die ACME-HTTP-01-Challenge beantwortet Traefik über
+den internen `acme-http`-Router mit maximaler Priorität, bevor dieser Redirect
+greift.
+
+### Abweichung der laufenden Traefik-Konfiguration (Live-Drift)
+
+`/srv/stack/docker-compose.yml` deklariert eine globale
+Entrypoint-Weiterleitung `http → https`
+(`--entrypoints.http.http.redirections.entryPoint.to=https` /
+`…scheme=https`, Zeilen 10–11). Der **laufende** Container `traefik` führt diese
+Flags nachweislich nicht (`docker inspect traefik --format '{{json .Args}}'`
+enthält keine `redirections`-Flags; `http://dennyapp.de/` leitet nur deshalb um,
+weil `landing` einen eigenen `landing-http`-Router besitzt). Die Datei auf der
+Platte und die laufende Konfiguration stimmen also nicht überein.
+
+Der Proxy wird deswegen **nicht** aus der Datei neu erzeugt oder neu gestartet:
+Das würde alle fremden Routen risikobehaftet anfassen. Stattdessen bringt jede
+Anwendung ihr eigenes HTTP-Routing mit — `desfoto.de` über die Labels in
+`compose.vps.yml`. Wird die globale Weiterleitung später bewusst aktiviert,
+bleibt der eigene Router schlicht wirkungslos.
+
+Nachzuprüfen mit:
+
+```bash
+curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://desfoto.de/
+# erwartet: 301 https://desfoto.de/
+```
 
 ## Rollback