Zusammenfassung

  • RFC 2397 definierte data: für kleine „unmittelbare“ Daten: optionaler Medientyp, optionales ;base64, ein Komma und die Daten.
  • Reisen die Bytes in der URL, liegt der wirksame Kontrollpunkt nicht mehr im externen Abruf, sondern beim lokalen Verbraucher, Medien-Handler und Pufferlimit.

Eine gewöhnliche URL verspricht eine Reise. Der Client liest einen Ort, kontaktiert ein externes System und erhält eine Darstellung. RFC 2397 kürzte diesen Weg. Bei data:[<mediatype>][;base64],<data> trägt die Zeichenfolge, die sonst nach außen weist, zugleich den zu lesenden Inhalt.

Das Dokument nannte dies „immediate addressing“. Hinter dem Komma steht kein winziger Server. Für das eingebettete Element trennt der Verbraucher Deklaration und Nutzlast, stellt die Oktette her und interpretiert sie nach dem Medientyp. Zeiger und Fracht werden zu einer einzigen serialisierten Eingabe.

Die Auslassungen sind genau geregelt. Ohne Medientyp gilt text/plain;charset=US-ASCII; text/plain darf entfallen, während ein charset angegeben wird. Das gleichheitszeichenlose ;base64 wählt Base64 und unterscheidet sich dadurch von einem normalen Content-Type-Parameter. Ohne diese Markierung stehen sichere URL-Zeichen direkt für Oktette, andere werden als %xx geschrieben. Base64 verschlüsselt und authentifiziert nicht.

Eine relative Form gibt es nicht. Eine relative Referenz bezieht ihre Basis aus dem Kontext; data: liefert Typ und Inhalt vollständig. Das trennt die Konstruktion von der Geschichte relativer URLs: Die eine leiht sich eine Adresse, die andere bringt ihre Bytes mit.

Die RFC beschränkt den Nutzen ausdrücklich auf kurze Werte. Sie nennt die SGML-Grenzen von HTML 2.0: 1.024 Zeichen für ein Attributliteral, 2.100 für alle Attributwerte eines Tags und 2.100 für das gesamte Tag. Selbst das kleine GIF-Beispiel lag nahe an der praktischen Grenze. Das sind keine universellen data:-Grenzen. Sie zeigen, dass Grammatik, umgebendes Format und Speicher verschiedene Längen vertragen können.

Der Sicherheitsabschnitt zeigt die Verlagerung der Macht. Ein Firewall-Proxy kann den externen Abruf eines verbotenen Medientyps verhindern. Bereits in einer URL enthaltene Daten lassen sich auf demselben Weg schwerer prüfen. Darum soll eine Anwendung einen durch ihre Konfiguration gesperrten Typ nicht interpretieren. Das wirksame Tor steht dort, wo Oktette zu Verhalten werden.

Zugleich war die Wirkung sehr langer Werte unbekannt; Software könne sich bei Daten jenseits ihres zugewiesenen Puffers unvernünftig verhalten. Zwei Prüfungen bleiben getrennt: Ist dieser Typ erlaubt? Kann diese Größe sicher verarbeitet werden? Der entfallene Fernabruf beantwortet keine davon.

Die Idee stammte vom August 1995. Genannt werden VRML, HTML-Einbettungsvorschläge, kommerzielle Produkte sowie Objektparameter in Java und ActiveX. Der Entwurf wurde verdichtet: Medientypen konnten entfallen, die Base64-Markierung wurde kürzer und quoted-printable verschwand, weil %xx bereits ausreichte.

Spätere Errata haben unterschiedliches Gewicht. Zwei Verified-Korrekturen ersetzen das unmögliche %fg und ändern den undefinierten RFC-2396-Begriff urlchar in uric. Fragen zu zitierten Parametern und Trennzeichen bleiben Reported oder Held for Document Update und sind kein bestätigter Ersatztext. Die pauschale Umbenennung von „URL“ in „URI“ wurde Rejected, weil der ursprüngliche Begriff historisch korrekt war.

Die bleibende Lehre betrifft Kontrolle. Ein kürzerer Weg beseitigt Autorität nicht; er konzentriert sie in der Software, die trennt, dekodiert, deutet und zulässt. Je weniger Vermittler beteiligt sind, desto klarer muss die lokale Grenze sein.

Quellen