Zusammenfassung

  • RFC 9659 verlangt von HTTP-zstd-Decodern Unterstützung bis einschließlich 8 MB Window_Size und verbietet Encodern Frames mit höherem Bedarf.
  • Gleiche URL und gleicher Content-Encoding-Header beweisen nicht, dass zwei Edges dieselben Bytes oder dieselbe Fenstergrenze ausliefern.
  • Ein belastbarer Nachweis verbindet Frame-Header und Objekt-Hash mit Transformation, Variantenschlüssel, Decoderbudget, Decodierergebnis und Anwendungsannahme.

Ein Edge lieferte die neue Objektgeneration aus; ein zweiter hielt noch die alte. Beide Antworten hatten dieselbe URL, denselben Status und denselben Content-Encoding: zstd-Header. Nur eine verlangte höchstens 8 MB. Wer nach URL oder Header aggregiert, sieht einen Dienst. Wer die Bytes betrachtet, sieht zwei unterschiedliche Interoperabilitätszustände.

RFC 9659 zieht für das HTTP Content Coding zstd eine gemeinsame Linie. Decoder MÜSSEN Window_Size bis einschließlich 8 MB unterstützen. Encoder DÜRFEN KEINE Frames erzeugen, die mehr verlangen. Diese Symmetrie verhindert, dass lokale Kompressionsoptimierung unbemerkt zum Speicherproblem des Empfängers wird.

Das Fenster gehört zum Frame

RFC 8878 beschreibt das Zstandard-Format. Das Fenster begrenzt, wie weit Back-References in bereits decodierte Daten zurückreichen dürfen, und damit einen Teil des Zustands, den ein Decoder halten muss. Das Format reicht von 1 KB bis ungefähr 3,75 TB. Ein größeres Fenster kann die Kompressionsrate verbessern, erhöht aber den möglichen Speicherbedarf.

RFC 8878 empfahl für HTTP bereits 8 MB, machte daraus jedoch keine Pflicht. So konnte ein Encoder ein größeres Fenster als zulässige Optimierung ansehen, während ein Browser es aus Ressourcenschutz ablehnte. RFC 9659 schließt diese Lücke. Der kanonische Text und die XML-Quelle zeigen dieselbe knappe Änderung.

Die RFC-Editor-Information ordnet RFC 9659 als Informational-Dokument ein, das RFC 8878 aktualisiert. Errata-Suche und Datatracker-Historie liefern die öffentliche Versionsspur, an die eine interne Regel gebunden sein sollte.

Aushandlung ist kein Ausführungsbeleg

RFC 9110 definiert die Semantik der Content Codings. Accept-Encoding: zstd teilt eine Fähigkeit für die Auswahl mit; Content-Encoding: zstd nennt die auf die gewählte Darstellung angewandte Transformation. Keiner der Header enthält das Zstandard-Fenster. Beide schweigen darüber, welcher Build den Frame erzeugte, ob ein Vermittler neu komprimierte, ob der Prozess Speicher bereitstellte und ob die Anwendung den Inhalt akzeptierte.

Eine Kennzahl für den Anteil von zstd-Antworten kann daher korrekt und trotzdem irreführend sein. Der Server zählt die Auswahl vor dem Decode. Das Edge zählt HTTP 200 vor dem Client. Kleine Canaries berühren die Grenze nicht. Ein Clientprodukt läuft mit verschiedenen Versionen und Ressourcenlimits. Der Header benennt den Vertrag; das Ergebnis entsteht später.

RFC 7694 behandelt Content Coding für Request Bodies. Auch dort ist die Anzeige akzeptierter Codings weder Beschreibung noch Verarbeitungsbeleg eines konkreten Bodys. Angebot, Auswahl, Bytes und Ergebnis müssen in beiden Richtungen getrennt bleiben.

Cache-Generationen sind operative Realität

RFC 9111 macht Caches zu einem Teil der HTTP-Auslieferung. Ein vor der Begrenzung erzeugtes Objekt kann weiterhin fresh sein. Ein Purge erreicht möglicherweise nicht alle Schlüssel. Eine Region kann eine andere Generation halten. Ein Fallback kann unter einer unklaren Variant-ID gespeichert werden.

Die prüfbare Einheit ist deshalb nicht die URL, sondern der ausgelieferte Byte-String. Benötigt werden Objekt-Hash, Variantenschlüssel, Generation, Alter, Invalidation, Transformationskette, Frame-Analyse und Empfängerklasse. Eine korrekte neue Origin-Version widerlegt kein altes fehlerhaftes Edge-Objekt. Die Zustände müssen nebeneinander sichtbar bleiben.

Das IANA-Register für HTTP-Parameter beschreibt zstd nun als Zstandard-Byte-Stream mit höchstens 8 MB Window_Size. Das Register schützt die öffentliche Bedeutung des Tokens. Es prüft keine gespeicherten Objekte. Der Registereintrag schafft die Erwartung; der Frame liefert den Nachweis.

Decoderfähigkeit und Prozessbudget trennen

Eine Bibliothek kann 8 MB unterstützen und in einem Prozess mit engerem Limit laufen. Speicherknappheit, Parallelität, Containergrenzen oder Timeout können die Allokation verhindern. Nach erfolgreichem Decode kann die Anwendung den Inhalt ablehnen. „Unterstützt zstd“ braucht daher Version, Einbettung, effektive Konfiguration, Zeitpunkt und Ergebnis.

Ein Empfängerbeleg enthält User-Agent oder Bibliothek, effektives Limit, beobachtetes Fenster, Decode-Ergebnis und Fehlerklasse. Übergroßes Fenster, Truncation, Korruption, unbekanntes Coding, Allocation-Fehler, Dictionary-Problem und Application-Reject sind keine einheitliche Störung.

RFC 9659 weist ausdrücklich darauf hin, dass übergroße, nicht konforme Frames eintreffen und beim Decode scheitern können. Unterstützung bis 8 MB bedeutet keine unbegrenzte Allokation. Korrekte Ablehnung außerhalb der Grenze unterscheidet sich von Versagen innerhalb der Grenze.

dcz ist ein anderer Vertrag

RFC 9842 definiert Compression Dictionary Transport und das Coding dcz. Dort kann die Fensterregel von der Dictionary-Größe abhängen und bis 128 MB reichen. Diese Regel gehört zu einem anderen Coding. Sie hebt RFC 9659 für gewöhnliches zstd nicht auf.

Eine gemeinsame Bibliothek kann beide Mechanismen hinter einem generischen Fensterregler verbergen. Der Beleg muss deshalb Coding-Token, Dictionary-Identität und Frame-Kontext enthalten. Gemeinsamer Code erzeugt keine gemeinsame Protokollbedeutung.

Die Kette bis zur Anwendung schließen

Beim Produzenten gehören Encoder-Version, effektive Konfiguration, Coding, Objekt-Hash und Frame-Header in den Nachweis. Jeder Vermittler dokumentiert Pass-through, Decode, Recompression oder Replacement. Der Cache dokumentiert Schlüssel, Generation, Freshness und Invalidation. Der Empfänger dokumentiert Version, Budget, Fenster, Ergebnis und Fehler. Die Anwendung dokumentiert Annahme statt sie aus Transportabschluss abzuleiten.

Sampling kann sich auf Grenzen konzentrieren: große Objekte, alte Generationen, verschiedene Edges, eingeschränkte Clients, Rollback, Fallback und Schlüsseländerungen. Warnsignale sind Frames über 8 MB, Hash-Unterschiede ohne Transformation, alte Objekte nach einer Cap-Änderung und Abstände zwischen Negotiation und Application Completion.

Heng Lus Minimum Initial Specification liefert die passende Form: eine kleine gemeinsame 8-MB-Regel mit klarer Fehlersicht und lokaler Freiheit innerhalb der Grenze. Reality Layers verhindern, dass das zstd-Label die Autorität eines Decode-Ergebnisses übernimmt. Running-Code Primacy gibt den tatsächlich ausgelieferten Bytes und dem tatsächlich ausgeführten Empfänger das letzte Wort.

RFC 9659 macht die Grenze gemeinsam. Objektidentität macht sichtbar, welcher Pfad sie eingehalten hat.

Quellen