it-swarm.com.de

Benötige ich Content-Type: application / octet-stream zum Herunterladen von Dateien?

Der HTTP-Standard sagt:

Wenn dieser Header [Content-Disposition: attachment] in einer Antwort mit dem Inhaltstyp application/octet-stream verwendet wird, wird impliziert, dass das Benutzerprogramm die Antwort nicht anzeigen soll, sondern direkt eine "save response as" eingibt. . 'dialog.

Ich lese das als

Content-Type: application/octet-stream
Content-Disposition: attachment

Aber ich hätte gedacht, dass Content-Typeapplication/pdf, image/png usw. wäre.

Soll ich Content-Type: application/octet-stream haben, wenn Browser die Datei herunterladen sollen?

373
Paul Draper

Nein.

Der Inhaltstyp sollte so sein, wie er bekannt ist, sofern Sie ihn kennen. application/octet-stream ist in RFC 2046 als "willkürliche Binärdaten" definiert, und es gibt hier eine eindeutige Überlappung, die für Entitäten geeignet ist, deren einziger Zweck darin besteht, auf der Festplatte gespeichert zu werden und von diesem Zeitpunkt an außerhalb von allem zu sein. " webby ". Oder um es aus einer anderen Richtung zu betrachten; Das einzige, was man mit application/octet-stream sicher machen kann, ist, es in einer Datei zu speichern und zu hoffen, dass jemand anderes weiß, wofür es ist.

Sie können die Verwendung von Content-Disposition mit anderen Inhaltstypen kombinieren, z. B. image/png oder sogar text/html, um anzugeben, dass Sie speichern und nicht anzeigen möchten. Es war früher so, dass einige Browser es im Fall von text/html ignorierten, aber ich glaube, das ist schon lange her (und ich gehe bald ins Bett, damit ich nicht anfange Testen Sie jetzt eine ganze Reihe von Browsern (vielleicht später).

RFC 2616 erwähnt auch die Möglichkeit von Erweiterungstoken, und heutzutage erkennen die meisten Browser inline, um zu bedeuten, dass die Entität nach Möglichkeit angezeigt werden soll (das heißt, wenn es sich um einen Typ handelt, den der Browser anzeigen kann, andernfalls hat er keine Wahl in der Sache). Dies ist natürlich sowieso das Standardverhalten, aber es bedeutet, dass Sie den filename -Teil in den Header einfügen können, den die Browser verwenden (möglicherweise mit einigen Anpassungen, damit die Dateierweiterungen den lokalen Systemnormen für den Inhaltstyp entsprechen) frage, vielleicht nicht) als vorschlag, ob der benutzer versucht zu speichern.

Daher:

Content-Type: application/octet-stream
Content-Disposition: attachment; filename="picture.png"

Bedeutet "Ich weiß nicht, was zum Teufel das ist. Bitte speichere es als Datei, vorzugsweise mit dem Namen picture.png".

Content-Type: image/png
Content-Disposition: attachment; filename="picture.png"

Bedeutet "Dies ist ein PNG-Bild. Bitte speichern Sie es als Datei, vorzugsweise mit dem Namen picture.png".

Content-Type: image/png
Content-Disposition: inline; filename="picture.png"

Bedeutet "Dies ist ein PNG-Bild. Bitte zeigen Sie es an, es sei denn, Sie wissen nicht, wie PNG-Bilder angezeigt werden. Andernfalls oder wenn der Benutzer es speichert, empfehlen wir den Namen picture.png für die Datei, unter der Sie es speichern".

Von den Browsern, die inline erkennen, würden einige immer verwenden, während andere es verwenden würden, wenn der Benutzer "Verknüpfung speichern unter" ausgewählt hätte, aber nicht, wenn sie beim Anzeigen "Speichern" ausgewählt hätten (oder zumindest IE war früher so, es hat sich vielleicht vor einigen Jahren geändert).

860
Jon Hanna