fix: Ingress auf Traefik umstellen — die nginx-Annotationen waren wirkungslos
Docker Image bauen und veroeffentlichen / build-and-push (push) Successful in 2m6s

Der Zielcluster nutzt Traefik, nicht ingress-nginx. Saemtliche Annotationen
der Form nginx.ingress.kubernetes.io/* ignoriert Traefik ersatzlos und
still: sie erzeugen keinen Fehler, wirken aber auch nicht. Das betraf das
Upload-Limit (proxy-body-size) ebenso wie die Zeitlimits, und
ingressClassName zeigte auf "nginx".

Damit aendert sich auch die Diagnose des fehlgeschlagenen Video-Uploads.
Belegt aus Traefiks Quelltext (pkg/config/static/static_config.go,
SetDefaults) und der Referenzdokumentation:

- readTimeout des EntryPoints: Default 60s, beschrieben als "maximum
  duration for reading the entire request, including the body". Er umfasst
  also die gesamte Uebertragung des Uploads. Bei 20-100 MB ueber eine
  normale Upload-Leitung ist das schnell ueberschritten — 80 MB bei
  10 Mbit/s sind rund 64 Sekunden. Laeuft er ab, kappt Traefik die
  Verbindung und antwortet mit einer eigenen HTML-Fehlerseite. Das ist die
  wahrscheinlichste Quelle des "Unexpected token '<'" im Browser.
- responseHeaderTimeout: von SetDefaults NICHT gesetzt, bleibt 0, und
  "If zero, no timeout exists". Die Dauer des ffmpeg-Transcodings ist bei
  Traefik also NICHT begrenzt — anders als zuvor angenommen.
- Body-Groesse: Traefik erzwingt keine Obergrenze (begrenzt ist nur
  maxHeaderBytes mit 1 MB fuer die Header). Ein Gegenstueck zu nginx'
  proxy-body-size wird nicht gebraucht.

readTimeout gehoert zur statischen EntryPoint-Konfiguration und laesst sich
nicht per Ingress-Annotation setzen. Das Manifest dokumentiert deshalb
ausfuehrlich, welche Einstellung in der Traefik-Installation noetig ist
(Helm: ports.websecure.transport.respondingTimeouts.readTimeout: 600s).

Weiter angepasst: ingressClassName auf "traefik", HTTPS-Umleitung ueber eine
Traefik-Middleware statt der nginx-Annotation, und der Hinweis zu
X-Forwarded-For nennt jetzt Traefiks forwardedHeaders.trustedIPs — davon
haengt ab, ob lib/rate-limit.ts dem Header trauen darf. Die Kommentare in
lib/uploads.ts und lib/csrf.ts verwiesen auf die entfernten
nginx-Einstellungen und sind entsprechend berichtigt.
This commit is contained in:
Nick Szaunig committed 2026-09-14 22:48:13 +02:00
1 parent 72d36f4716
commit e8f0bd4f55
3 files changed
+98 -47

No files matched your search

+6 -3
View File
@@ -5,9 +5,12 @@ import { getBaseUrl } from "@/lib/url";
*
* Reihenfolge nach Verlaesslichkeit:
* 1. X-Forwarded-Host — der oeffentliche Host, den der eigene Reverse-Proxy
* (Caddy/nginx, siehe Caddyfile bzw. k8s/06-ingress.yaml) weiterreicht.
* Caddy verwirft einen vom Client mitgeschickten X-Forwarded-Host per
* Default, der Wert stammt hier also immer vom Proxy selbst.
* (Caddy bzw. Traefik, siehe Caddyfile bzw. k8s/06-ingress.yaml)
* weiterreicht. Caddy verwirft einen vom Client mitgeschickten
* X-Forwarded-Host per Default; bei Traefik entscheidet darueber
* "forwardedHeaders.trustedIPs" des EntryPoints — nur fuer dort
* aufgefuehrte Absender werden eingehende X-Forwarded-*-Header
* uebernommen, von allen anderen ersetzt.
* 2. Host — der Host, den der Browser tatsaechlich adressiert hat. Das ist
* die massgebliche Groesse fuer eine Same-Origin-Pruefung und genau der
* Vergleich, den Next.js fuer Server Actions intern selbst anstellt.
+9 -3
View File
@@ -67,9 +67,15 @@ export const MAX_INPUT_PIXELS = 100_000_000;
* groesser sind. Diese Grenze gilt fuer die ROHDATEI vor dem Transcoding
* (siehe lib/video-transcode.ts transcodeVideoForWeb, aufgerufen in
* app/api/admin/upload-video/route.ts) — das tatsaechlich gespeicherte,
* web-optimierte Ergebnis ist danach in aller Regel deutlich kleiner. Muss
* zum "proxy-body-size" in k8s/06-ingress.yaml passen (dort grosszuegiger
* bemessen).
* web-optimierte Ergebnis ist danach in aller Regel deutlich kleiner.
*
* Der vorgeschaltete Proxy muss eine Datei dieser Groesse durchlassen. Bei
* Traefik (dem hier eingesetzten Ingress-Controller) gibt es keine Grenze
* fuer die Body-Groesse, wohl aber eine fuer die Uebertragungsdauer:
* "readTimeout" des EntryPoints umfasst das Lesen des gesamten Requests
* inklusive Body und steht per Default auf 60s — zu wenig, um 100 MB ueber
* eine normale Upload-Leitung zu schicken. Siehe die ausfuehrliche Notiz in
* k8s/06-ingress.yaml.
*/
export const MAX_UPLOAD_VIDEO_BYTES = 100 * 1024 * 1024;