Vor ein paar Monaten saß ich beim Onboarding eines neuen Mandanten. Mittelständischer Maschinenbauer, 180 Mitarbeiter, hauseigenes ERP-Frontend auf ASP.NET Core. Der Entwickler — kompetent, seit acht Jahren im Unternehmen — zeigte mir die Fehlermeldung, die seit Wochen sporadisch auftauchte: HTTP 400, Request Header Too Large. Nur bei bestimmten Nutzern, nur nach einer Weile Nutzungsdauer. Die Ursache? Ihr Auth-Cookie war über die 4-KB-Grenze gewachsen. Drin steckten: User-ID, Tenant-ID, Abteilung, alle 47 Berechtigungen als Strings, drei UI-Präferenzen und — ich zitiere den Kommentar im Code — "legacy field, do not remove".
Das ist kein Einzelfall. Das ist ein Pattern.
Was Khalid Abuhakmeh erklärt
Khalid Abuhakmeh beschreibt in seinem Artikel das Problem sauber: Cookies sind auf 4 KB begrenzt. ASP.NET Core verwendet Cookies intensiv für Session-State und Auth-Daten — verschlüsselt, Base64-kodiert, komprimiert. Das frisst Platz schneller, als man denkt. Seine Lösung ist der ChunkingCookieManager, eine Abstraktion hinter ICookieManager, die große Cookies automatisch auf mehrere kleinere Cookie-Header aufteilt. Die Registrierung ist überschaubar, die API konsistent, und das Ergebnis im Browser-DevTools sieht dann so aus: chunky_monsterC1, chunky_monsterC2, und so weiter. Der Artikel ist technisch korrekt, gut geschrieben, und das Code-Beispiel funktioniert. Wenn du .NET-Entwickler bist und dieses Problem hast, ist das ein solider Ausgangspunkt.
Was er nicht beantwortet — und das ist keine Kritik, das ist schlicht nicht sein Scope — ist die Frage, ob du an diesem Punkt überhaupt noch Cookie-Chunking willst.
Wie das im Mittelstand wirklich landet
Das Problem mit dem 4-KB-Limit ist fast immer ein Symptom. Die eigentliche Krankheit heißt: zu viel Zustand im Cookie.
Ich sehe das regelmäßig. Ein Cookie, der an die Grenze stößt, hat typischerweise eine von drei Ursachen:
1. Zu viele Claims auf einmal. Das Berechtigungsmodell wurde über Jahre ausgebaut, jede neue Funktion hat einen eigenen Claim bekommen, und irgendwann ist aus "IsAdmin: true" ein Dictionary mit 60 Einträgen geworden. Alle landen im Auth-Cookie. Alle werden bei jedem Request mitgeschickt — auch beim Laden eines 2-KB-Favicons.
2. Daten, die nicht in den Cookie gehören. Ich habe Cookies gesehen, die den vollständigen Anzeigenamen, die E-Mail-Adresse, die Abteilung, den Vorgesetzten und den letzten Login-Zeitpunkt enthielten. Das sind Profildaten. Die gehören in eine Datenbank und werden bei Bedarf abgerufen — nicht bei jedem Request mitgeschleppt.
3. Multi-Tenant-Exzesse. In Mandanten mit mehreren Kunden oder Standorten werden Tenant-Kontexte manchmal vollständig in den Cookie serialisiert, weil "dann brauchen wir keinen Datenbankaufruf". Stimmt. Aber du zahlst stattdessen mit Netzwerk-Overhead auf jedem Request, und irgendwann knallt es.
Khalid nennt selbst das Extrembeispiel: 10 Cookies à 4 KB, macht 40 KB zusätzliche Last pro Request. Das ist keine Randnotiz — das ist ein Alarmsignal, das bedeutet, die Architektur hat ein ernstes Problem, das Cookie-Chunking nicht löst.
Was ich meinen Mandanten empfehle
Schritt eins: Cookie-Autopsie. Bevor du irgendetwas implementierst, schau dir an, was tatsächlich in deinem Cookie steckt. In ASP.NET Core reicht ein kleines Middleware-Stück, das im Development-Environment den entschlüsselten Cookie-Inhalt loggt. Was du in 80 % der Fälle findest: 40–60 % des Inhalts sind redundant oder könnten woanders gespeichert werden.
Schritt zwei: Slim-Down zuerst. Entferne aus dem Cookie alles, was sich leicht aus dem Server-Zustand rekonstruieren lässt. User-ID, Tenant-ID, Session-Identifier — das reicht als Minimal-Set. Alles andere (Berechtigungen, Profildaten, UI-Präferenzen) holst du bei Bedarf aus einem Server-seitigen Cache. Redis ist dafür die Standardlösung, und in einer KMU-Umgebung mit 30 bis 300 Nutzern kostet eine Redis-Instanz auf Azure oder dem eigenen Server weniger als eine Stunde Entwicklerzeit pro Monat.
Schritt drei: Erst dann ChunkingCookieManager — wenn überhaupt. Wenn du nach dem Slim-Down immer noch an die Grenze stößt, ist ChunkingCookieManager eine saubere Lösung. Die Implementierung ist wie im Artikel beschrieben unkompliziert. Achte dabei auf drei Dinge, die Khalid erwähnt, aber die in der Praxis oft übersehen werden:
ThrowForPartialCookies = truegehört auftrue. Fehler bei der Reassemblierung still zu schlucken führt zu subtilen, schwer debuggbaren Auth-Fehlern.- Du musst konsequent den
ICookieManagernutzen — nicht mal hier, mal da direkt aufHttpContext.Response.Cookies. Mischbetrieb produziert korrupte Chunks. - Wenn du Cookie-Optionen wie
SecureoderSameSitesetzt, musst du das auf jedem Chunk konsistent tun. Das passiert automatisch, wenn du alles überICookieManagerabwickelst — aber es ist gut, das explizit zu wissen, wenn du mal im Debugger landest.
Was ich nicht empfehle: Den ChunkingCookieManager als Pflaster zu verwenden, ohne die Root Cause zu verstehen. Zwei Cookie-Chunks heute, vier in einem Jahr, sechs nach dem nächsten Feature-Sprint. Irgendwann merkst du, dass du pro Request 20 KB Cookie-Overhead mit dir rumschleppst, alle davon verschlüsselt, alle davon müssen reassembliert werden. Der CPU- und Speicherbedarf dafür ist gering — bis er es nicht mehr ist. Bei 200 gleichzeitigen Nutzern in einem kritischen ERP-Prozess ist "gering" relativ.
Die eine Zahl, die zählt
Wenn dein Auth-Cookie größer als 1,5 KB ist, lohnt sich eine halbe Stunde Analyse. In meiner Erfahrung können Entwickler, die das erste Mal systematisch schauen, was wirklich drin steckt, den Cookie-Inhalt in 60–70 % der Fälle auf unter 600 Byte reduzieren — ohne Funktionsverlust. Das ist der eigentliche Quick-Win. Cookie-Chunking ist der technisch korrekte Plan B.
Der vollständige Original-Beitrag von Khalid Abuhakmeh: ASP.NET Core and Chunking HTTP Cookies
Hast du gerade ein ASP.NET Core Projekt, bei dem die Cookie-Größe oder Auth-Performance ein Thema ist? Dann reden wir 30 Minuten Klartext darüber — ohne Vorbereitung, ohne Verkaufsgespräch.
— Bernhard