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-Type
application/pdf
, image/png
usw. wäre.
Soll ich Content-Type: application/octet-stream
haben, wenn Browser die Datei herunterladen sollen?
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).