Unbekannter Dateityp MIME?


Antworten:


184

Sie können application/octet-streamfür unbekannte Typen verwenden.

RFC 2046- Zustände in Abschnitt 4.5.1:

Der Subtyp "Oktettstrom" wird verwendet, um anzuzeigen, dass ein Körper beliebige Binärdaten enthält.


3
Tatsächlich sollten Sie pro RFC keine Typinformationen mit unbekannten Daten senden. RFC-2046 definiert nur bekannte Typen, aber RFC-7231 zeigt Ihnen, wie Sie mit unbekannten Typen umgehen.
Sampo Sarrala - codidact.org

@SampoSarrala Ich habe RFC-7231 etwas anders gelesen: "Wenn kein Headerfeld für den Inhaltstyp vorhanden ist, kann der Empfänger entweder einen Medientyp" Anwendung / Oktett-Stream "([RFC2046], Abschnitt 4.5.1) oder annehmen Untersuchen Sie die Daten, um ihren Typ zu bestimmen. " Ich interpretiere dies so, dass wir entweder KEINEN Inhaltstyp senden sollten oder dass wir sicher sind, standardmäßig Anwendung / Oktett-Stream zu senden, wenn wir nicht möchten, dass Kunden Ratespiele mit Inhaltsprüfung spielen.
Jpnh

1
@Jpnh Ja, das stimmt. Der Content-Type-Header sollte nicht vorhanden sein, wenn er unbekannt ist. Man könnte auch einen Anwendungs- / Oktett-Stream senden, der dem Client im Grunde sagt, dass " Sie ihn gerade nicht anzeigen möchten, sondern diese Bytes stattdessen in einer Datei speichern ". Dadurch bieten Web-Clients das Speichern von Dateien an. Option 1 == Sie wissen nichts über diese Datei. Option 2 == Dateiinhalte können nicht mit MIME beschrieben werden oder sollten nur auf der Festplatte gespeichert werden. In der Praxis wäre jede Option richtig. Ich hätte eine bessere Formulierung wählen sollen, um Verwirrung zu vermeiden.
Sampo Sarrala - codidact.org

4
"Beliebige Binärdaten" sind nicht "unbekannt". Durch die Verwendung von application / octet-stream teilen Sie dem Browser mit, dass der Inhaltstyp bekannt ist, weder Text noch ein Bild, sondern beliebige Binärdaten sind und daher in eine Datei heruntergeladen und möglicherweise ausgeführt werden sollten. Abgesehen davon, dass dies falsch ist, ist dies eine Sicherheitslücke, insbesondere angesichts der kaum sichtbaren modernen Download-Manager. Die richtige Antwort ist kein Header vom Typ Inhalt. Wenn Sie nicht wissen, um welche Art von Datei es sich handelt, kann der Browser dies wissen. Lassen Sie es also raten, insbesondere wenn er den Verwendungskontext (Bild, Dokument, Skript, ...)
kennt

@FF_Dev Ich bin sicher, das ist Unsinn. "Beliebige Binärdaten" bedeuten nicht "ausführbar"; Es gibt keinen Grund, warum ein Browser (oder Download-Manager) davon ausgehen sollte, dass eine application/octet-streamDatei ausführbar ist. Und selbst wenn ein Browser wird wissentlich eine ausführbare Datei herunterzuladen, ist es nicht „ausführen möglicherweise“ es ohne den Benutzer auffordert , zu; Das bloße Herunterladen einer ausführbaren Datei bedeutet nicht, dass ich möchte, dass sie jetzt ausgeführt wird. Wenn es wirklich einen Browser gibt, der application/octet-streamDateien beim Herunterladen automatisch ausführt , teilen Sie uns mit, welcher und wie das Verhalten reproduziert werden soll. Im Moment glaube ich dir nicht.
Mark Amery

38

RFC-Ressourcen:

Wir sollten RFC-7231 (HTTP / 1.1-Semantik und -Inhalt) als Referenz anstelle von RFC-2046 (Medientypen) verwenden, da die Frage eindeutig den HTTP-Inhaltstyp betraf.

Auch RFC-2046 definiert unbekannte Typen nicht klar, RFC-7231 jedoch.

Kurze Antwort:

Senden Sie keinen MIME-Typ für unbekannte Daten.
Um es klarer zu machen: Verwenden Sie überhaupt keinen Content-Type-Header.

Verweise:

RFC-7231
Hypertext Transfer Protocol (HTTP / 1.1): Semantik und Inhalt
3.1.1.5. Inhaltstyp

Ein Absender, der eine Nachricht mit einem Nutzdatenkörper
generiert, MUSS in dieser Nachricht ein Headerfeld für den Inhaltstyp generieren, es sei denn, der
beabsichtigte Medientyp der beigefügten Darstellung ist dem
Absender unbekannt .

In diesem Abschnitt wird Ihnen klar gesagt, dass Sie es weglassen sollen, wenn Sie es nicht genau wissen. Es sagt auch, dass der Empfänger annehmen könnte, dass der Typ Anwendung / Oktett-Stream ist, aber die Sache ist, dass es auch etwas anderes sein könnte.

Was ist dann anders?

RFC-2046
4.5.1. Octet-Stream-Subtyp

Die empfohlene Aktion für eine Implementierung, die eine
"application / octet-stream" -Entität empfängt , besteht darin, einfach anzubieten, die Daten
in eine Datei zu legen, wobei die Inhaltsübertragungscodierung rückgängig gemacht wird, oder sie möglicherweise
als Eingabe für eine benutzerdefinierte zu verwenden Prozess.

Und wie oben bereits erwähnt:

RFC-7231
3.1.1.5. Inhaltstyp

Wenn kein Header-Feld für den Inhaltstyp vorhanden ist, kann der Empfänger entweder einen Medientyp "Anwendung / Oktett-Stream"
([RFC2046], Abschnitt 4.5.1) annehmen oder die Daten untersuchen, um ihren Typ zu bestimmen.

Fazit:

Wenn Sie es als "Anwendung / Oktett-Stream" definieren, sagen Sie, dass Sie wissen, dass es "Anwendung / Oktett-Stream" ist.

Wenn Sie es nicht definieren, sagen Sie, dass Sie nicht wissen, was es ist, und überlassen die Entscheidung dem Empfänger, und der Empfänger könnte dann prüfen, ob es wie Ente läuft und ...


1
Diese Antwort verdient eine positive Bewertung, da sie die einzige in der Wahrheit ist. Wenn Sie standardmäßig "application / octet-stream" verwenden, lösen die meisten Browser den Download aus. Dies ist eine Sicherheitslücke, wenn man die fast unsichtbaren modernen Download-Manager berücksichtigt.
FF_Dev

1
Dies ist für HTTP korrekt, aber die Frage bezieht sich auf MIME im Allgemeinen und nicht auf HTTP. In E-Mails zum Beispiel sind die Regeln völlig anders. Siehe auch Diskussion unter vorgeschlagenem Duplikat stackoverflow.com/questions/12539058/…
Tripleee

Ich habe aus dem gleichen Grund einen Aufwärtstrend gegeben, stimme jedoch FF_Dev zu. Sofern nicht beabsichtigt ist, "Anwendung / Oktett-Stream" zu sein und einen Download auszulösen, besteht Bedarf an "Anwendung / Unbekannt". Es wäre schön, wenn die Browser nicht versuchen würden, die Datei herunterzuladen, wenn die "Inhaltsdisposition" nicht festgelegt wäre, aber es gibt zu viele Websites, die willkürlich Dateien herunterladen, ohne ihren Dateinamen für die Verwendung festzulegen. Vor allem Banken.
Justdan23

14

Ich bevorzuge application/unknown, aber das Ergebnis wird sicherlich das gleiche sein wieapplication/octet-stream


17
Gibt es einen Standard, der die Verwendung von application / unknown anstelle von application / octet-stream erlaubt?
Hendrik Brummermann

3
Vielen Dank! application / unknown funktioniert hervorragend, Octet-Stream führt zu einem Chrome-Fehler in meiner Beispiel-PNG-Datei!
fnkr

10
Warum eine PNG-Datei als application/octet-streamoder bereitstellen application/unknown? Es gibt einen Grund, warum sie erfunden haben image/png.
Aidiakapi

10
@ jenson-button-event Es hat nichts mit der Neuerfindung des Rades zu tun. Der MIME-Typ gibt Ihre Absicht an. Wenn Sie wissen, dass das, was Sie senden, ein PNG-Bild sein soll, geben Sie diese Informationen weiter. Wenn die Bytes versehentlich ein JPEG darstellen, kann Ihre Anwendung Sie warnen, dass es sich nicht um ein gültiges PNG handelt und dass Sie irgendwo anders einen Fehler haben. Darüber hinaus sind nicht alle Anwendungen so robust und fehlertolerant wie ein Browser. Sie wurden entwickelt, um die Fehler des Programmierers zu beheben, aber das ist bei weitem nicht der einzige Zweck. Ein Browser ist nicht die einzige Anwendung, die MIME-Typen verwendet.
Aidiakapi

2
Was ist Ihre Referenz? Der unbekannte Typ liefert keine Informationen über den Inhalt oder den Status der Datei, oder selbst wenn er binär oder textbasiert ist, ist er für Produktionscode zu dunkel und für ein kleines Projekt möglicherweise in Ordnung, da ein Dateimimetyp keine hat Handler im Betriebssystem ist es im Wesentlichen eine herunterladbare Binärdatei - und der unbekannte Typ ist ein bekanntes Handle im Windows-Betriebssystem, dem Sie eine Aktion zuweisen können (z. B. das Öffnen unbekannter Dateien mit dem Editor). Obwohl es eine schlechte Praxis ist, können Sie den unbekannten Typ in Kombination damit verwenden , um jede Ausführung zu überspringen: /
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.