Zusammenfassung

  • ICAP OPTIONS kündigt Methoden, Preview-Größe, Transferbehandlung, Allow, Kapazität, Gültigkeit und ISTag an; nach Ablauf ist die alte Fähigkeit keine aktuelle Zusage.
  • Ein belastbarer Nachweis verbindet die damals gültigen Fähigkeiten mit den tatsächlich gesehenen Bytes, dem Servicezustand, Cache und Transformation sowie dem nächsten HTTP- und Anwendungsergebnis.

Ein Client sendete weiterhin die Preview-Größe, die er am Vortag erhalten hatte. Der Dienst hatte seine Regeln und Kapazität geändert. Die Anpassung antwortete dennoch, und das Dashboard verbuchte die Transaktion als vollständig geprüft.

Das Problem war nicht zwingend ein fehlerhafter Statuscode. Der Client hatte eine abgelaufene Aussage über Fähigkeiten wie eine zeitlose Vereinbarung behandelt. Aus einer technisch beantworteten Anfrage wurde eine unbelegte Aussage darüber, unter welchen Bedingungen sie beantwortet worden war.

RFC 3507 erschien im April 2003 als Informational RFC und dokumentierte ein damals bereits eingesetztes Protokoll. ICAP ist ein eigenständiges TCP-Protokoll, das HTTP-Abschnitte kapselt; es ist weder HTTP noch läuft es über HTTP. Die IESG-Notiz hält außerdem fest, dass ICAP den in RFC 3238 beschriebenen Architektur- und Politikfragen für OPES vorausging.

OPTIONS ist ein Angebot mit Ablaufdatum

Die OPTIONS-Methode kann unterstützte ICAP-Methoden, Preview-Größe, Transferlisten, Allow, maximale Verbindungen, Gültigkeitsdauer und ISTag liefern. Der Client darf diese Angaben nur im beschriebenen Zeitfenster als aktuelle Fähigkeit behandeln.

Nach Ablauf muss er die Fähigkeiten neu ermitteln, statt alte Werte stillschweigend fortzuschreiben. Ein Dienst kann die Preview verkleinern, bestimmte Übertragungen anders behandeln, 204 anders erlauben oder eine neue Serviceepoche aktivieren.

Ein HTTP-200 auf die spätere Anpassungsanfrage erneuert die frühere OPTIONS-Aussage nicht automatisch. Der Beleg braucht die konkrete OPTIONS-Antwort, ihr Empfangs- und Ablaufdatum und die Transaktion, die sich darauf stützte.

Die Preview-Grenze liegt innerhalb des Körpers

Ein ICAP-Client sendet alle gekapselten Header und bis zur angekündigten Zahl von Body-Bytes. Dann beendet er den Preview-Chunkstrom vorläufig und wartet.

Der Dienst kann ein angepasstes Ergebnis, 204 No Content oder – falls weitere Bytes existieren – 100 Continue liefern. Anders als beim bekannten HTTP-Mechanismus kann die Pause bereits nach einigen Body-Bytes liegen.

Damit gehören angeforderte und tatsächliche Preview-Länge, Kapselungsoffsets, Chunkgrenzen, Ursprungslesestand und erstes nicht gesendetes Byte zum Urteil. Die historische Mindestfähigkeit von 4096 Bytes ist keine universelle Klassifikationsschwelle.

Wird eine abgelaufene Preview-Größe benutzt, ist nicht nur die Zahl alt. Auch die Annahme darüber, welche Last und welche Beobachtungsfläche der Dienst akzeptiert, kann falsch sein.

100 Continue erneuert OPTIONS nicht

Reicht die Preview nicht bis zum Bodyende, kann der ICAP-Dienst mit 100 Continue den Rest anfordern. Der Client fährt mit dem ersten Chunk nach der Preview fort.

Diese Zwischenantwort sagt: Sende den restlichen gekapselten Input. Sie sagt nicht, dass die OPTIONS-Antwort wieder gültig ist, dass die Anpassung erfolgreich endet oder dass ein HTTP-Origin die Operation akzeptiert.

In einer Spur können deshalb mehrere provisorische Grenzen vorkommen. ICAP fordert mehr Input, später kann HTTP eigene Zwischen- und Endantworten besitzen. Telemetrie muss Absender, Verbindung und Ressource jeder Antwort nennen.

ieof beendet die Möglichkeit weiterer Daten

Wenn der Origin während der Preview endet, markiert der Client den letzten Chunk mit ieof. Der Dienst weiß dann, dass das wirkliche Bodyende innerhalb der Preview lag.

Er darf nicht mit 100 Continue nach mehr Daten fragen, sondern kann eine Anpassung oder gegebenenfalls 204 zurückgeben. Vor der Übergabe an die Anwendungslogik entfernt der Dienst die Erweiterung.

Deshalb braucht die Prüfung sowohl den Drahtnachweis mit ieof als auch den Anwendungsbuffer. Das Fehlen von ieof verspricht umgekehrt nicht, dass weitere Bytes tatsächlich eintreffen; die Quelle kann später abbrechen.

204 beschreibt Rekonstruktion, nicht Reinheit

In einer Preview erlaubt 204 No Content dem Client, so fortzufahren, als sei die vollständige Nachricht unverändert zurückgekommen. Das funktioniert, weil der Client den vorab gesendeten Teil gepuffert hat und den Rest noch besitzt.

Außerhalb der Preview kann der Client mit Allow: 204 dieselbe Verantwortung übernehmen. Ohne diese Erlaubnis muss der Dienst eine vollständige identische Nachricht zurückgeben, wenn er nichts ändern will.

Der Status verteilt Speicher-, Rückstau- und Wiederherstellungskosten. Er bescheinigt weder Malwarefreiheit noch Authentizität oder Policykonformität. Der Dienst kann eine Änderung nicht wünschen oder nicht leisten können.

Ein sauberer Nachweis enthält Pufferstand, Rekonstruktionspfad und Hash des wiederhergestellten Originals – nicht bloß die Zahl 204.

ISTag markiert eine Serviceepoche

Jede ICAP-Antwort muss ein ISTag tragen. Der Wert kann Software, Konfiguration oder Entscheidungsdaten des Dienstes repräsentieren. Ändert sich ein Zustand so, dass alte Anpassungsergebnisse ungültig werden, ermöglicht ein neues Tag deren Invalidierung.

Der Geltungsbereich ist breiter als bei einem ETag für eine HTTP-Repräsentation. Ein Service-Tag kann viele vom selben ICAP-URI erzeugte Objekte betreffen.

Es ist aber keine kryptografische Attestierung. Es nennt keine Regeln und beweist nicht, dass alle Clusterknoten umgestellt wurden. Der Beleg bindet das Tag an Konfigurationsmanifest, Knoten, Aktivierungszeit und Invalidierungsaktion.

Drei Uhren entscheiden über Wiederverwendung

Die erste Uhr ist die OPTIONS-Gültigkeit. Die zweite ist die Cachefrische des angepassten Ergebnisses. Die dritte ist die Gültigkeit der Serviceepoche, die durch ISTag vergleichbar wird.

In RESPMOD darf das Ablaufdatum eines angepassten Origin-Objekts nicht später liegen als das des Originals, kann aber früher sein. Diese Regel schützt die Herkunftsfrische, nicht die Aktualität der Anpassungspolitik.

Ein Cache-Hit ist deshalb kein zeitloses Urteil. Er ist Wiederverwendung unter Fähigkeiten, Schlüsseln, Daten und einer Serviceepoche, die im Entscheidungszeitpunkt belegt werden müssen.

REQMOD kann einen HTTP-Fehler vor dem Origin erzeugen

Im Request-Modification-Modus kann der Dienst eine geänderte Anfrage, eine HTTP-Fehlerantwort, ein erlaubtes 204 oder einen ICAP-Fehler liefern. Ein gekapselter HTTP-Fehler kann vom Anpassungspfad stammen, ohne dass der Origin die Anfrage je gesehen hat.

Im Response-Modification-Modus kann die Origin-Antwort vor dem Empfänger verändert werden. Ein erfolgreich angepasstes Objekt ist noch kein erfolgreich ausgeliefertes oder verarbeitetes Objekt.

Vorher-/Nachher-Hashes, Regel, Dienstidentität, ISTag und Ergebnis des nächsten Hops bewahren die Provenienz. Der authentisierte Anwendungseffekt bleibt ein eigener Beleg.

Offsets machen das Kompositum lesbar

Der Header Encapsulated enthält Offsets für Request-Header und -Body, Response-Header und -Body, OPTIONS-Body oder Null-Body. Er trennt die Abschnitte, validiert aber nicht sämtliche HTTP-Semantik.

Chunkrahmung, Preview-Ende, ieof, ICAP-Endstatus und eingebetteter HTTP-Status gehören zu verschiedenen Schichten. Wer nur das neu serialisierte HTTP speichert, kann genau die Grenze verlieren, die den Beobachtungsumfang erklärt.

Autorität kommt nicht aus einer Capability-Antwort

RFC 3238 und spätere OPES-Dokumente behandeln Einwilligung, Benachrichtigung, Privatsphäre, URI- und Referenzfragen, Regeln, Vertrauensdomänen und Tracing. Sie machen nicht jede ICAP-Installation zu OPES und verwandeln OPTIONS nicht in ein Mandat.

Der Dispatcher muss belegen, wessen Regel den Dienst auswählte, in welcher Vertrauensdomäne er handelte und wie die Veränderung kenntlich gemacht wurde. Technische Fähigkeit und politische Befugnis sind getrennte Aussagen.

Eine zeitlich gebundene Beweiskette

Beginnen Sie mit ursprünglichen HTTP-Bytes, Rolle und Beobachtungspunkt. Speichern Sie ICAP-URI, Methode, Peers, OPTIONS-Inhalt, Empfang, Ablauf und ISTag. Prüfen Sie die Offsets.

Erfassen Sie angeforderte und empfangene Preview, ieof, Origin-Lesestand und Buffer. Bewahren Sie 100 oder Endstatus, Resttransfer und den tatsächlich gesehenen Bytebereich.

Bei Änderung gehören Vorher, Nachher und Regel dazu; beim Cache Schlüssel, Daten und Tag; bei 204 die genaue Rekonstruktion. Danach folgen nächster HTTP-Hop, Herkunft, Zustellung, Autorisierung und authentisiertes Anwendungsergebnis.

Evidenzgrenze

Dieser Beitrag benennt kein aktuelles Produkt, keinen Proxy, Scanner oder Vorfall. Er behauptet nicht, OPTIONS-Caching oder Preview seien falsch. Er verweigert nur eine zeitlose Lesart befristeter Fähigkeiten.

Er wiederholt auch nicht den bestehenden Beitrag über HTTP 100 Continue, der die Erlaubnis zum Senden eines Request-Bodys an der HTTP-Grenze untersucht. Hier geht es um ausgehandelte Anpassungsfähigkeiten, Kapselung und Serviceepochen.

Heng Lus Prinzipien einer minimalen Anfangsspezifikation und des Vorrangs laufenden Codes sind offengelegte redaktionelle Perspektiven. Sie bevorzugen einen schmalen gemeinsamen Vertrag und Messung des ausgeführten Pfads; sie messen keine ICAP-Verbreitung.

Die begrenzte Schlussfolgerung lautet: Eine alte Fähigkeit bleibt nicht wahr, nur weil der Dienst noch antwortet. Ihr Ablauf gehört zum Urteil.

Sources