outline: Upload-Grenzen von Anwendung und Ingress liegen um Faktor zehn auseinander #12
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#12
Reference in new issue
Block a user
Der Chart setzt zwei Obergrenzen für Datei-Uploads, die um den Faktor zehn auseinanderliegen. Die kleinere gewinnt, und sie steht an der Stelle, an der niemand sucht.
Belegt
outline/values.yaml:Auswirkung
Die Anwendung meldet ihren Benutzern eine Obergrenze von 250 MiB — das ist der Wert, den sie in der Oberfläche sieht und gegen den sie prüft. Der Ingress-Controller bricht aber schon bei 25 MB ab, mit einem 413 aus nginx, bevor die Anfrage die Anwendung überhaupt erreicht.
Das Fehlerbild ist entsprechend irreführend: die Oberfläche sagt „bis 250 MiB erlaubt", der Upload einer 100-MB-Datei scheitert trotzdem, und in den Protokollen der Anwendung steht nichts, weil die Anfrage dort nie ankam.
Zu entscheiden
Es ist nicht von vornherein klar, welcher der beiden Werte der falsche ist — das ist eine Betriebsentscheidung, keine reine Chart-Frage:
values.yamldokumentieren — dann muss aber dort stehen, dass die kleinere Grenze gilt und warum.Was auch immer gewählt wird: die beiden Werte gehören in
values.yamlmit einem Kommentar aneinander gebunden, sonst läuft dasselbe beim nächsten Anfassen wieder auseinander.Gefunden bei
Umsetzung von #157/#43 für
outline(PR #180, inzwischen gemergt). Der Entwicklungs-Agent hat die Abweichung in der neuenNOTES.txtdokumentiert, sodass sie beim Installieren immerhin sichtbar ist — die Werte selbst hat er bewusst nicht angefasst, weil das eine Verhaltensänderung wäre und außerhalb seines Auftrags lag. Die Zahlen wurden anschließend unabhängig anorigin/maingegengeprüft.Versionsfolge
Eine Änderung an einer der beiden Grenzen ändert das Laufzeitverhalten des Ingress bzw. der Anwendung → nach den Konventionen ein Major-Sprung. Reine Dokumentation in
values.yamlwäre ein Patch.Nachgeprüft am 2026-10-04: unverändert offen
Beide Werte stehen wie beschrieben, der Faktor zehn ist unberührt:
outline/values.yaml:15maxUploadSize: '262144000'outline/values.yaml:92maxUploadFileSize: 25mDie wirksame Grenze ist die kleinere: der Ingress weist bei 25 MB ab, bevor die Anwendung ihre 250 MB überhaupt sieht. Ein Nutzer, der eine 100-MB-Datei hochlädt, bekommt also einen Fehler vom Reverse Proxy, während die Anwendung so konfiguriert ist, als dürfte er es.
Zu entscheiden, bevor jemand es behebt: welche der beiden Zahlen die gewollte ist. Beide Richtungen sind je eine Zeile, aber sie bedeuten Verschiedenes — 250 MB heißt, der Ingress wird angehoben; 25 MB heißt, die Anwendung wird heruntergesetzt und die Nutzer bekommen die Grenze, die sie heute faktisch schon haben.
Nutzt Outline kein Chunking für größere Dateien? Dann wären zwei Limits richtig, und das ingress-limt müsste über der maximalen chunk-size liegen
Die Lage hat sich mit dem Gateway-Modus geändert — gelöst ist nichts
Mit PR #117 (Teil von #114, gemergt am 12.10.2026) kann
outlinealternativ zur Ingress eineHTTPRouterendern. Das berührt dieses Issue, und zwar in eine Richtung, die die Entscheidung unten schwerer macht, nicht leichter.Der Stand bleibt wie belegt
Unverändert auf
origin/main:Der Faktor zehn steht also weiter, und die beiden Werte sind inzwischen in
values.yamlaneinandergebunden (Zeile 105 nennt beide zusammen mit dem Faktor) — das war die Mindestforderung am Ende des Issue-Rumpfs und ist erfüllt. Die Betriebsentscheidung selbst ist offen.Was neu hinzukommt
Im Gateway-Modus verschwindet die Ingress-Hälfte. Die Gateway-API kennt keine Body-Size — das ist implementierungsspezifische Politik, und nach Entscheidung 1 von #114 rendert der Chart ausdrücklich kein implementierungsspezifisches Policy-Objekt, weil ihn das an eine Implementierung binden würde.
ingress.maxUploadFileSizewird in diesem Modus also nicht durchgesetzt;outline/values.yaml:139benennt das, und der Gateway-Zweig vonNOTES.txtdruckt es beim Installieren aus.Die wirksame Grenze ist damit das Kleinere aus
outline.maxUploadSizeund dem, was das Gateway durchsetzt — und die zweite Zahl steht nirgends im Chart, weil er sie nicht kennen kann.Warum das die Diagnose verschlechtert
Heute ist die Lage unangenehm, aber geschlossen: zwei Zahlen, beide in
values.yaml, die kleinere gewinnt. Wer das Fehlerbild einmal kennt, findet die Ursache an einer Stelle, an der sie steht.Im Gateway-Modus ist keine der beiden dokumentierten Zahlen zwingend die entscheidende. Das Fehlerbild bleibt dasselbe — die Oberfläche verspricht 250 MB, der Upload scheitert, in den Protokollen der Anwendung steht nichts, weil die Anfrage dort nie ankam —, aber die Antwort steht nicht mehr in der Werte-Datei. Sie steht in einem Objekt in einem anderen Repository, das dieser Chart nicht nennt.
Das ist, gemessen am Diagnoseaufwand, schlechter als der Faktor zehn, der dieses Issue ausgelöst hat.
Was das für die Entscheidung bedeutet
Die drei Optionen im Rumpf bleiben gültig, bekommen aber eine vierte Eigenschaft:
outline.maxUploadSizedie Anwendung selbst konfiguriert. Das ist der einzige der drei Hebel, der modusunabhängig greift — ein Argument für diese Option, das es vor #114 nicht gab.Eine Lösung, die auch im Gateway-Modus eine durchgesetzte Grenze herstellt, hieße ein implementierungsspezifisches Policy-Objekt zu rendern — also genau die Portabilität aufzugeben, die der Modus kauft. Das ist in #114 bewusst ausgeschlossen worden und wird hier nicht wieder aufgemacht.
Status
Dieses Issue bleibt offen und wartet weiter auf die Betriebsentscheidung. Es hat sich durch #114 nichts erledigt; die Entscheidungsgrundlage ist nur vollständiger geworden. Nachgetragen am 12.10.2026 nach dem Merge von #117.