Zusammenfassung

  • RFC 2068 vom Januar 1997 definierte das HTTP-Feld Link für Beziehungen zwischen Ressourcen, meist zwischen der angeforderten und einer weiteren. Eine Entität konnte mehrere Werte enthalten; die Semantik ähnelte dem HTML-Element LINK.
  • RFC 5988 vom Oktober 2010 hält fest, dass RFC 2616 vom Juni 1999 das Feld wegen fehlender Implementierungserfahrung entfernte. Dadurch blieb sein Status unklar, obwohl einige Benutzeragenten es später verwendeten und weitere Anwendungsfälle entstanden.
  • RFC 5988 beschrieb das Feld erneut, nun in einem Modell typisierter Links unabhängig von einem einzelnen Dokumentformat. RFC 8288 vom Oktober 2017 löste dieses Dokument ab und behielt Link als HTTP-Darstellung einer Ressourcenbeziehung bei.

Der Link reist mit der Antwort

Ein Link in einer HTML-Seite gehört zum Dokument. Der Browser liest ein Element und entscheidet anhand der Beziehung, ob er etwas anzeigen oder abrufen soll. Doch nicht jede Webressource kommt als HTML zurück. Die gleiche Ressource kann in einem anderen Format dargestellt werden. Steht die Beziehung nur im HTML-Körper, erhält ein Leser der anderen Darstellung möglicherweise keinen Hinweis. Ein HTTP-Feld übermittelt die Beziehung bereits mit der Antwort, bevor ihr Körper interpretiert wird.

Der HTTP/1.1-Standard RFC 2068 vom Januar 1997 sah genau diesen Ort vor. Abschnitt 19.6.2.4 definierte Link als Feld, das eine Beziehung zwischen zwei Ressourcen beschreibt, gewöhnlich der angeforderten Ressource und einer weiteren. Eine Entität durfte mehrere Werte tragen. rel benannte die Beziehung, title lieferte eine lesbare Beschriftung, anchor konnte einen anderen Ausgangspunkt festlegen. Der Text verglich das Feld ausdrücklich mit dem HTML-Element LINK. Ein Wegweiser konnte im Umschlag der Antwort stehen, statt im Inhalt der Seite.

Der Ort bestimmt, wer den Wegweiser sehen kann. HTML-Markup erreicht Leser, die HTML interpretieren. Ein HTTP-Feld begleitet auch eine Antwort mit einem anderen Medientyp. Ein Client, der es versteht, erkennt die typisierte Beziehung unabhängig vom Format des Körpers. Er entscheidet selbst, ob er das Ziel abruft, anzeigt oder für seine Aufgabe ignoriert. Das Feld stellt eine Beziehung fest; es führt den nächsten Schritt nicht aus.

RFC 2068 ordnete Link unter zusätzlichen Funktionen ein. Im selben Bereich beschrieb es die Anfragemethoden LINK und UNLINK, mit denen Beziehungen eingerichtet oder entfernt werden sollten. Diese Methoden sind andere Mechanismen als ein Feld in der Antwort. Die spätere Wiederaufnahme des Feldes ist keine Wiederaufnahme der Methoden. Gleiche Wortbestandteile reichen für eine gemeinsame Implementierungsgeschichte nicht aus.

Die Ausgabe von 1999 lässt eine Lücke

RFC 2616 vom Juni 1999 ersetzte RFC 2068 ohne Definition des Link-Feldes. Der Grund ist durch RFC 5988 belegt: Es war wegen mangelnder Implementierungserfahrung entfernt worden. Die Autoren der HTTP/1.1-Neufassung hatten einen beschriebenen Vorschlag, aber zu wenig Praxis, um ihn in den neuen Grundtext aufzunehmen.

Damit ist eine Entscheidung über den Standard dokumentiert, keine vollständige Bestandsaufnahme der Server und Browser des Jahres 1999. Datiertes Quellmaterial zu Produkten und aufbewahrte HTTP-Antworten würden zeigen, wer das Feld tatsächlich sendete oder verstand. Die vorliegenden Dokumente zeigen bereits, dass eine plausible und zuvor veröffentlichte Funktion ihren Platz in der nächsten Ausgabe verlieren konnte, wenn der Betrieb sie nicht ausreichend trug.

Das Fehlen hatte eine weitere Folge. RFC 5988 schrieb später, der Status von Link sei unklar geworden. Manche erwogen daher, für jede Anwendung eigene HTTP-Felder zu schaffen, statt ein Feld mit zweifelhafter Stellung weiterzuverwenden. Eine allgemeine Aufgabe drohte in viele lokale Namen zu zerfallen: Wie beschreibt eine Ressource ihre Verbindung zu einer anderen, wenn ihr Inhalt nicht immer HTML ist?

Das Dokument von 2010 berichtet außerdem, dass einige Benutzeragenten das Feld später implementiert hatten, etwa für Stylesheets, und weitere Einsatzzwecke entstanden. Es spricht von einigen Agenten, nicht von sämtlichen Browsern. Diese begrenzte Aussage erklärt, warum die Frage mit neuen Beispielen auf den Tisch zurückkam.

Die Rückkehr löst den Link vom HTML-Körper

RFC 5988 vom Oktober 2010 spezifizierte Link mit aktualisierter, rückwärtskompatibler Syntax. Vor allem beschrieb es eine Beziehung unabhängig von ihrem Träger. Ein typisierter Link besteht aus Kontext, Relationstyp, Ziel und möglichen Zielattributen. Dieselbe Beziehung lässt sich als HTML-Element, Atom-Element oder HTTP-Feld ausdrücken. Die Art der Übermittlung bestimmt nicht die Bedeutung des Links.

Das löst ein konkretes Problem. Eine Ressource kann mehrere Darstellungsformate besitzen. Wenn ihre Beziehung nur in einer HTML-Fassung liegt, verliert der Empfänger einer anderen Fassung diese Information. Das HTTP-Feld kann mit jeder Antwort reisen. Ein Link im HTML-Körper bleibt für einen HTML-Leser nützlich. Die Spezifikation bietet beiden Formen ein gemeinsames Modell, während die Anwendung entscheidet, welche Relation sie nutzt.

RFC 5988 erweiterte auch das aus Atom bekannte Verzeichnis der Relationstypen um Beziehungen aus HTML. Ein eingetragener Relationstyp sagt, was die Verbindung bedeutet. Er garantiert weder, dass das Ziel antwortet, noch zwingt er jeden Client zu einer Aktion. Ein Browser sucht vielleicht ein Stylesheet; ein Archivwerkzeug interessiert sich für eine andere Ausgabe oder eine Lizenz. Ein gemeinsames Vokabular erzeugt noch keine einheitliche Handlung.

RFC 8288 vom Oktober 2017 ersetzte RFC 5988 und behielt Kontext, Relationstyp, Ziel und optionale Attribute bei. Das HTTP-Feld Link blieb eine von mehreren Darstellungsformen. Der Text unterscheidet etwa Webnavigation, die stylesheet in HTML und gegebenenfalls im HTTP-Feld sucht, von einer Atom-Anwendung mit anderen Relationen. Der Relationstyp beschreibt die Verbindung von Ressourcen; der Medientyp beschreibt das Format der Darstellung, die beim Abruf eines Ziels zurückkommt. Beides beantwortet verschiedene Fragen.

Deshalb war die Rückkehr von 2010 mehr als das Wiedereinfügen eines Absatzes. 1997 brachte das Feld eine dem HTML-Link ähnliche Struktur in HTTP. 2010 und 2017 gaben den Beziehungen ein formatübergreifendes Modell und ein Verfahren für ihre Namen. Das wiederkehrende Feld hatte eine klarere Aufgabe.

Eine zweite Runde von Betriebserfahrung

Die Abfolge wirkt sprunghaft, wenn Veröffentlichung und Nutzung gleichgesetzt werden. 1997 war die Idee konkret genug für eine Beschreibung. 1999 reichte die Erfahrung für einen dauerhaften Platz im Grundstandard noch nicht. 2010 konnte die neue Spezifikation einige Anwendungen und weitere Bedürfnisse nennen; 2017 ging das Modell in eine Nachfolgenorm über. Die Redakteure bestimmten die Stelle im Text. Die laufenden Programme beeinflussten, wie gut sich diese Entscheidung begründen ließ.

Es geht um mehr als einen Feldnamen. Eine Beziehung im HTML-Körper gehört zu genau dieser Darstellung. Im HTTP-Feld kann sie auch mit einem anders formatierten Körper sichtbar sein. Herausgeber und Leser erhalten einen gemeinsamen Ort für typisierte Verbindungen, ohne jede Ressource als Webseite auszugeben.

Für eine genaue Einsatzkurve fehlen datierte Client- und Serverversionen oder bewahrte Antworten. Die RFCs belegen den institutionellen Bogen: Ein Feld wurde definiert, wegen dünner Betriebserfahrung entfernt und mit einem breiteren Modell für Beziehungen außerhalb des HTML-Körpers wieder aufgenommen.