Zusammenfassung

  • RFC 3229 erweiterte bedingtes GET: Der Client nennt gespeicherte Instanzen in If-None-Match, bietet Transformationen in A-IM an und kann statt einer Vollkopie 226 mit einem IM-Rezept erhalten.
  • Drei Identitäten steuern die Rekonstruktion. Delta-Base nennt die alte Basis, der Körper enthält die Differenz, und der Antwort-ETag bezeichnet die rekonstruierte aktuelle Instanz—nicht die Delta-Bytes.
  • Der neue Status schützte alte Caches. Ein unbekanntes Feld zu ignorieren konnte dazu führen, dass ein Delta als vollständige Ressource gespeichert wurde; 226 machte den Bedeutungsbruch sichtbar.

Bedingte Übertragung sparte alles oder nichts

War eine gespeicherte Antwort noch aktuell, vermied 304 Not Modified die erneute Kopie. Änderte sich die Ressource auch nur geringfügig, kam normalerweise der vollständige neue Wert.

Der Cache war ein binärer Zeuge: unverändert verwendbar oder für die nächste Übertragung nutzlos. Eine neue Zeile schickte alle alten Zeilen wieder durchs Netz.

Der im Januar 2002 veröffentlichte RFC 3229 machte die alte Kopie zur Rekonstruktionsbasis. Der Server konnte den Unterschied zur aktuellen Instanz berechnen und nur die nötigen Anweisungen übertragen.

Die Erweiterung blieb optional, sollte mittlere Antwortgrößen ohne zusätzliche Runde senken und mit ahnungslosen HTTP/1.0- und HTTP/1.1-Systemen koexistieren. Nicht jede Änderung musste ein lohnendes Delta ergeben.

Delta war weder Kompression noch Range

Die Spezifikation definiert Instanz als den Wert eines 200 GET für die ausgewählte Variante nach Content-Coding, aber vor Instanzmanipulation und Transfer-Coding.

Kompression lässt sich ohne alte Kopie rückgängig machen. Ein Delta braucht die konkrete Basis. Range wählt Koordinaten aus einer aktuellen Instanz; Delta beschreibt den Übergang zwischen zwei Instanzen. Beide reduzieren womöglich Bytes, doch ihre Belege unterscheiden sich.

226 ist auch kein PATCH. Der Körper beantwortet GET und hilft dem Empfänger, den aktuellen Zustand wiederherzustellen. Er verlangt keine Änderung der Ressource. RFC 3229 spezifiziert den Mechanismus nicht für andere Methoden.

Diese Trennung schützt die Herkunft vor einem unscharfen Begriff „inkrementell“.

Der Client musste seinen Ausgangspunkt belegen

If-None-Match listet ETags alter Instanzen, die der Client besitzt. A-IM nennt Manipulationen, die er ausführen kann.

Ist eine Marke noch aktuell, genügt 304. Bei Änderung kann ein fähiger Server eine angebotene Basis wählen und ein kompatibles Delta erzeugen. Fehlen Version, Verfahren oder Nutzen, bleibt 200 möglich.

Das ist ein Angebot, kein Befehl. Der Client kontrolliert vorhandene Basen und Formate. Der Ursprung kontrolliert Historie, Rechenaufwand, Basiswahl und Vollantwort.

„Unterschied“ wird erst sicher, wenn beide Seiten wissen: von welchem Zustand und mit welcher Operation?

Eine Antwort koordinierte drei Objekte

Die alte Basis liegt im Cache. Der 226-Körper trägt Anweisungen. Deren Anwendung erzeugt die aktuelle Instanz.

Bei mehreren angebotenen ETags nennt Delta-Base die gewählte Basis. Der Antwort-ETag benennt das Ergebnis. RFC 3229 betont, dass er nicht zum Delta gehört, denn ein Delta ist keine eigenständige Instanz.

Der Körper kann korrekt und allein dennoch unbrauchbar sein. Er benötigt exakte Basis, Transformation und Ausgangsidentität.

Auch Content-Length misst den Delta-Körper, nicht die rekonstruierte Instanz. Eine Verwechslung macht die Einsparung zur scheinbaren Verstümmelung.

Die Reihenfolge gehörte zur Provenienz

Die konzeptionelle Kette wählt Ressource und Variante, führt Content-Coding aus, vergibt den Instanz-ETag, wendet Delta oder Range an und zuletzt Transfer-Coding.

Die Stufen sind nicht vertauschbar. Delta vor Range kann anderes ergeben als Range vor Delta. Kompression als Content-Coding wirkt auf die Instanzidentität; als spätere Manipulation liegt sie anders.

A-IM und IM bewahren die Reihenfolge. Ein Cache darf nicht nur Namen speichern und beim Wiedergebrauch neu sortieren. Basis, Algorithmus, Parameter und Sequenz bilden das Rezept.

Gesparte Bytes bleiben nur wahr, wenn die Anleitung zu ihrer Rückverwandlung erhalten bleibt.

Ein neuer 2xx hielt unwissende Caches auf

Die Autoren wollten zunächst keinen weiteren Status. Das Verhalten installierter Vermittler machte ihn nötig.

HTTP verlangt meist, unbekannte Felder zu ignorieren. Ein alter Proxy konnte IM ignorieren, den Delta-Körper speichern und später als vollständige Ressource ausgeben. Erweiterbarkeit hätte stillen Datenfehler erzeugt.

Der unbekannte 226 bildete eine deutlichere Grenze. Laut RFC schienen vorhandene Proxies unbekannte Zustände weiterzuleiten, ohne sie zu cachen. Sie konnten transportieren, ohne Verständnis vorzutäuschen.

Selbst Vary: If-None-Match, A-IM reichte in mindestens einem Fehlvalidierungsszenario nicht. Die Semantik musste dort sichtbar sein, wo alte Logik sie nicht leicht zu 200 ebnete.

IM beschrieb das Rezept, 226 stoppte die Ganzheitsannahme

Eine Delta-Antwort muss 226 verwenden und in IM mindestens das Delta-Verfahren nennen. Die Anfrage muss es über A-IM akzeptiert und über If-None-Match eine Basis angeboten haben.

Der Status sagt, dass GET durch eine oder mehrere Instanzmanipulationen erfüllt wurde. Je nach Rezept entsteht die aktuelle Instanz erst zusammen mit früheren oder späteren Antworten.

226 ist daher nicht nur ein Synonym für Delta. Der Rahmen kann Range und weitere Manipulationen kombinieren. IM speichert die Sequenz; 226 warnt davor, den Körper sofort als vollständige Instanz zu verwenden.

Die kurze Phrase „IM Used“ ersetzt keine strukturierten Rekonstruktionsfelder.

Ein fähiger Cache konnte rekonstruieren

Ein generelles Speicherverbot hätte Nutzen vernichtet. RFC 3229 trennt unwissende von vollständig konformen Caches.

Ein fähiger Cache kann alle Manipulationen dekodieren, die aktuelle Instanz herstellen und als 200 speichern. Er kann nur Range stehenlassen und 206 speichern oder den rohen 226 unter Sonderregeln behalten.

Rohe Wiederverwendung verlangt kompatible Manipulationen, Parameter und Reihenfolge in der nächsten Anfrage sowie Frische-, Basis- und Identitätsbedingungen. Ein gespeichertes Delta wird nicht zur unabhängigen Variante.

Die Cache-Control-Direktive im markiert die Fähigkeitsgrenze: no-store hält gewöhnliche Caches ab; nur Implementierungen mit Verständnis für 226, A-IM und IM folgen den Spezialregeln.

Vergangenheit zu behalten kostete Ressourcen

Ein nützliches Delta braucht eine erhaltene Basis. Der Client kann mehrere Instanzen behalten und mehrere ETags anbieten. Besitzt der Ursprung passende Historie, wählt er die geeignete Basis und nennt sie in Delta-Base.

Doch Speicher und Historie sind endlich, Kandidatenvergleich kostet CPU, RAM und I/O. Ein Retention-Hinweis ist kein ewiges Versprechen.

Die Optimierung ändert Anreize: Eine alte Kopie bleibt vielleicht nicht zur Anzeige, sondern als künftige Basis. Der Ursprung sollte Versionen oder vorberechnete Deltas nur erhalten, wenn erwartete Einsparung die Kosten deckt.

Der Rückfall auf 200 ist operative Kontrolle. Ist das Delta größer, langsamer oder nicht vorhanden, ist die Vollantwort besser.

Heutige Register erhalten die Grammatik

Das IANA-Verzeichnis der HTTP-Statuscodes führt 226 IM Used zu RFC 3229. Das IANA-Verzeichnis der HTTP-Feldnamen führt A-IM, Delta-Base und IM dauerhaft.

Registrierung beweist keine breite Nutzung. Sie bewahrt die Zuordnung von Symbol und Vertrag und verhindert widersprüchliche Wiederverwendung.

Die historische Lehre ist nicht ein universeller Sieg des Deltas. Sie zeigt, wie viel Identität HTTP behalten musste, um weniger zu senden und trotzdem das Richtige zu liefern.

Die Kopie entstand erst nach der Rekonstruktion

Mit 226 durften Netzwerknachricht und aktuelle Darstellung verschiedene Dinge sein. Das Netz trug eine Transformation, ohne sie zum vollständigen Ergebnis zu erklären.

Der Client belegte die Basis, der Server wählte sie, IM fixierte die Reihenfolge, der ETag benannte die Ausgabe, und der Cache verstand die Kette oder verzichtete auf Umdeutung.

Ohne Herkunft ist ein Delta keine effiziente Wahrheit, sondern eine kurze Bytefolge mit unsichtbarer Voraussetzung.

HTTP 226 machte diese Voraussetzung sichtbar: Der Empfänger bekam nicht die neue Kopie, sondern ein überprüfbares Verfahren, sie aus einer nachweislich vorhandenen alten Kopie zu erzeugen.