Zusammenfassung

  • Mit download kann eine HTML-Seite das Speichern einer verlinkten Ressource wünschen und einen Dateinamen vorschlagen; der HTTP-Server kann einen eigenen Namen liefern.
  • Ein Mozilla-Ticket von 2013 und eine WHATWG-Debatte von 2017 zeigen, warum Downloads über Herkunftsgrenzen mehr als eine Etikettenfrage sind.

Auf dem Knopf steht „Bericht herunterladen“. In Gedanken liegt bericht.pdf schon ordentlich im Download-Ordner. Dabei haben zwei Absender einen Stift in der Hand: die Seite mit dem Link und der Server mit der Datei. Ein dritter Akteur muss den Zettel annehmen und die Datei tatsächlich auf dem Rechner ablegen. Der Browser spielt Pförtner, Lagerist und gelegentlich Schiedsrichter. Für ein einziges Wort im HTML ist das eine beachtliche Karriere.

Die Sprache des Servers beschreibt RFC 6266 vom Juni 2011. Im HTTP-Feld Content-Disposition fordert attachment zur Speicherung auf; filename empfiehlt einen Namen, filename* auch mit internationalen Zeichen. Das Dokument verlangt, solche Namen als Hinweise zu behandeln. Pfadbestandteile dürfen keinen fremden Speicherort diktieren, und eine verdächtige Endung verdient einen zweiten Blick. Der Server verschickt ein Paket mit Beschriftung. Die Schlüssel zum lokalen Dateisystem besitzt er deshalb noch lange nicht.

Die Webseite bekam später ihren eigenen Stift. Die Plattformübersicht des Chromium-Projekts führt a[download] ab M14. Das Attribut sagt: Diesen Link bitte als Download behandeln; sein Wert schlägt einen Dateinamen vor. Für eine erzeugte Grafik oder eine bereitgestellte Tabelle ist das angenehm. Der Link auf der einen Domain kann aber auf eine Datei einer anderen Domain zeigen. Plötzlich steht die Frage im Raum, ob der Gastgeber des Knopfs auch die fremde Datei benennen und als Download auslösen darf.

Ein Mozilla-Fehlerbericht von 2013 machte den Konflikt anklickbar. Ein Link zu einem Bild auf einer anderen Website trug download="filename.png". Firefox zeigte das Bild an, Chrome speicherte es. Der Melder wollte die Ergebnisse angleichen; Mozilla bezeichnete das Firefox-Verhalten als notwendige Sicherheitsmaßnahme und schloss das Ticket. Unter derselben sichtbaren Oberfläche lagen zwei unterschiedliche Vorstellungen davon, wie weit die Anweisung einer fremden Seite reichen sollte.

Im April 2017 stellte ein WHATWG-Issue die Varianten nebeneinander. Firefox und Safari ignorierten damals in diesem Fall das Attribut; Chrome speicherte die Ressource, verwarf aber den von der Seite vorgeschlagenen Namen. Ein Standards-Editor erklärte, beide Wege seien nach dem damaligen Algorithmus möglich, und regte eine Angleichung an. Speichern und Benennen erwiesen sich als zwei getrennte Entscheidungen. Zur selben Zeit meldete WebKit die Einführung des Attributs in Safari 10.1 für macOS, einschließlich Downloads aus Blob-Daten. Die Funktion hatte einen klaren Nutzen und einen Rand, an dem Browser ihre Verantwortung ausloten mussten.

Der heutige HTML-Standard verteilt die Aufgaben deutlich. download drückt den Wunsch der Seite aus und empfiehlt gegebenenfalls einen Namen. Content-Disposition aus der Antwort kann diese Empfehlung überstimmen. Bei einer anderen Herkunft soll attachment vom Server der Ressource die Absicht zum Download bekräftigen. Der Browser entscheidet schließlich über einen sicheren lokalen Namen und Speicherort.

Das kleine Namensschild zeigt, wie Macht im Web wandert. Die Seite entwirft den Knopf. Der Server liefert den Inhalt. Der Browser kontrolliert den Übergang auf den Rechner. Wenn der Klick reibungslos wirkt, ist die Verhandlung gelungen. Das Etikett im Download-Ordner ist ihr knappes Protokoll.