- HTTP-Cookies: Kleine Datenstücke, die verwendet werden, um den Zustand im Web aufrechtzuerhalten; nachdem sie vom Browser gesetzt wurden, werden sie bis zu ihrem Ablauf bei allen HTTP-Anfragen mitgesendet.
- Problem tritt auf: Bestimmter JavaScript-Code konnte Cookies in der Go-Standardbibliothek nicht parsen, was zu einem Fehler führte.
Spezifikation
- RFC 2109, 2965, 6265: Frühe Definitionen und Aktualisierungen von Cookies. Die Spezifikation für Cookie-Werte stimmt zwischen Servern und Browsern nicht überein.
- Probleme:
- Was Server senden sollen und was Browser akzeptieren müssen, stimmt nicht überein.
- Es gibt keine Einschränkungen für Cookie-Werte, die Browser an Server senden.
- Es gibt keine klaren Richtlinien dafür, wie Standardbibliotheken Cookie-Header verarbeiten sollen.
Webbrowser
- Firefox: Erlaubt einige Zeichen, die in den RFCs nicht empfohlen werden.
- Chromium: Etwas restriktiver als Firefox, erlaubt aber weiterhin viele Zeichen.
- Safari: Wenn ein nicht erlaubtes Zeichen auftritt, wird die Cookie-Verarbeitung nicht abgebrochen; stattdessen wird der Wert bis zu diesem Zeichen akzeptiert.
Standardbibliotheken
- Golang: Verhält sich ähnlich wie die RFCs, erlaubt aber Leerzeichen und Kommas.
- PHP: Wirft bei bestimmten Steuerzeichen einen Fehler.
- Python: Ignoriert Cookies, die es nicht versteht, und beendet das Laden weiterer Cookies.
- Ruby: Akzeptiert alle Zeichen und percent-encodiert sie.
- Rust: Akzeptiert alle UTF-8-Strings.
Bedeutung für das Web
- Praktisches Problem: Aufgrund der Mehrdeutigkeit der Spezifikation können viele Websites leicht Fehler verursachen.
- Lösung: Die IETF HTTP Working Group sollte die Cookie-Spezifikation aktualisieren und klarstellen, wie Browser und Programmiersprachen Cookies verarbeiten sollen.
Zusammenfassende Tabelle
- Cookie-Verarbeitung in Browsern und Sprachen: Jeder Browser und jede Sprache verarbeitet Cookies anders. Auch die Übereinstimmung mit den RFCs variiert.
1 Kommentare
Hacker-News-Kommentare
Cookies enthalten unerwartete Probleme und unangenehme Verhaltensweisen und funktionieren in 99,95 % der Fälle. Cookie Shadowing ist ein Problem, das auftritt, wenn Cookies mit demselben Namen, aber unterschiedlichen Schlüsselattributen (Domain, Pfad usw.) gesetzt werden; dann können Backend oder JS nicht unterscheiden, um welches Cookie es sich handelt
Rust hat in der Standardbibliothek keine Funktion zur Cookie-Verarbeitung und orientiert sich am Verhalten der Third-Party-Crate "cookie". Diese enthält wie Ruby eine Option für Percent-Encoding
Das HTTP-Protokoll umfasst zahlreiche andere Protokolle, und Browser sowie Webserver fügen verschiedene Funktionen hinzu. Für diese Funktionen gibt es keine klaren Spezifikationen, und Client und Server können keine Kompatibilität festlegen. Daher ist man gezwungen, frühere Fehlentscheidungen weiterzutragen
Vor etwa 10 Jahren gab es in einem Projekt bei der Implementierung Cookie-basierter Sessions ein Problem: In Safari funktionierte es, in Chrome jedoch nicht. Der Grund war der Unterschied darin, dass Browser Cookies nicht setzen, wenn das Format nicht korrekt ist
Die einzig vernünftige Verwendung von Cookies besteht darin, ein undurchsichtiges Token zu setzen, damit der Server den Client erkennen kann. Dass der Client einen Wert verarbeiten kann, den der Server nicht senden würde, ist dabei kein Problem
Cookies sind ein komplexes Problem, und wegen Abwärtskompatibilitätsproblemen sind Änderungen nahezu unmöglich. Es besteht Bedarf an einem neuen Mechanismus. Zum Beispiel könnte ein NewCookie-Mechanismus moderne Sicherheitsmaßnahmen und strenge Spezifikationen mitbringen
Cookies sollten verschwinden und durch Authentifizierungs-Header ersetzt werden. Es wäre gut, wenn man sich im Browser auf standardisierte Weise bei Websites authentifizieren könnte. Schade, dass Basic- und Digest-Authentifizierung nicht ausgereicht haben
Da der Networking-Code von Safari nicht Open Source ist, könnte der Foundation-Port von Swift eine gute Alternative sein. Dort lassen sich Steuer- und Löschzeichen überprüfen
Das Parsen von Cookie-Headern ist verwirrend. Der "Standard" spiegelt nicht wider, was tatsächlich existiert, und jeder Backend-Server, jede Bibliothek und jedes Framework akzeptiert etwas anderes. Wenn man Frontend und Backend vollständig kontrollieren kann, ist das kein großes Problem, aber sobald man mit anderen Systemen interagieren muss, wird es sehr kompliziert
Bei Experimenten mit der Sprache Crystal gab es ein ähnliches Problem. Es sollte ein einfacher Web-Scraper gebaut werden, aber der Standard-HTTP-Client konnte viele der in der Antwort gesetzten Cookies nicht parsen und brach ab