Nieznany typ pliku MIME?

140

Czy muszę określać typ MIME, jeśli przesyłany plik nie ma rozszerzenia? Innymi słowy, czy istnieje domyślny ogólny typ MIME?

mime mime-types default-value Shimmy Weitzhandler
źródło

Odpowiedzi:

184

Możesz użyć application/octet-streamdla nieznanych typów.

RFC 2046 stwierdza w sekcji 4.5.1:

Podtyp „Octet-stream” służy do wskazania, że treść zawiera dowolne dane binarne.

Bombe
źródło

Właściwie zgodnie z RFC nie powinieneś wysyłać żadnych informacji o typie z nieznanymi danymi. RFC-2046 definiuje tylko znane typy, ale RFC-7231 mówi, jak postępować z nieznanymi typami.

Sampo Sarrala - codidact.org

@SampoSarrala Odczytuję RFC-7231 trochę inaczej: "Jeśli nie ma nagłówka Content-Type, odbiorca MOŻE albo przyjąć typ mediów" application / octet-stream "([RFC2046], Rozdział 4.5.1) lub zbadać dane, aby określić ich rodzaj. " Interpretuję to tak, że powinniśmy albo wysyłać NO Content-Type, albo możemy bezpiecznie wysyłać aplikację / strumień oktetu jako domyślny, jeśli nie chcemy, aby klienci grali w gry w zgadywanie z badaniem treści.

Jpnh

@Jpnh Tak, zgadza się. Nagłówek Content-Type nie powinien być obecny, jeśli jest nieznany. Można również wysłać application / octet-stream, który zasadniczo mówi klientowi, że " nie chcesz go teraz wyświetlać, ale zamiast tego zapisz te bajty do pliku ". To sprawia, że klienci sieciowi oferują zapisywanie pliku. Opcja 1 == Nie wiem nic o tym pliku. Opcja 2 == Zawartość pliku nie może być opisana za pomocą mime lub powinna być zapisywana tylko na dysku. W praktyce obie opcje byłyby poprawne. Powinienem był wybrać lepsze sformułowanie, aby uniknąć nieporozumień.

Sampo Sarrala - codidact.org

„Dowolne dane binarne” nie są „nieznane”. Używając application / octet-stream, informujesz przeglądarkę, że typ zawartości jest znany, nie jest to tekst ani obraz, ale dowolne dane binarne i w rezultacie powinny zostać pobrane do pliku i prawdopodobnie wykonane. Oprócz tego, że jest to błąd, jest to luka w zabezpieczeniach, szczególnie biorąc pod uwagę ledwo widoczne nowoczesne menedżery pobierania. Prawidłowa odpowiedź to brak nagłówka typu treści. Jeśli nie wiesz, jaki to rodzaj pliku, przeglądarka może go znać, więc niech zgadnie, zwłaszcza gdy zna kontekst użycia (obraz, dokument, skrypt, ...)

FF_Dev

@FF_Dev Jestem pewien, że to nonsens. „Dowolne dane binarne” nie oznaczają „plików wykonywalnych”; nie ma powodu, dla którego przeglądarka (lub menedżer pobierania) miałaby zakładać, że application/octet-streamplik jest wykonywalny. A nawet jeśli przeglądarka jest świadomie pobierając plik wykonywalny, to nie „ewentualnie wykonać” bez użytkownik pytaniem; Samo pobranie pliku wykonywalnego nie oznacza, że chcę go teraz wykonać. Jeśli naprawdę istnieje przeglądarka, która może application/octet-streamautomatycznie uruchamiać pliki podczas pobierania, powiedz nam, która i jak odtworzyć to zachowanie. Teraz ci nie wierzę.

Mark Amery,

Zasoby RFC:

Powinniśmy użyć RFC-7231 (semantyka i zawartość HTTP / 1.1) jako odniesienia zamiast RFC-2046 (typy mediów), ponieważ pytanie dotyczyło wyraźnie HTTP Content-Type.

Również RFC-2046 nie definiuje jasno nieznanych typów, ale RFC-7231 tak.

Krótka odpowiedź:

Nie wysyłaj typu MIME dla nieznanych danych.
Żeby było jaśniej: w ogóle nie używaj nagłówka Content-Type.

Bibliografia:

RFC-7231
Hypertext Transfer Protocol (HTTP / 1.1): semantyka i zawartość
3.1.1.5. Typ zawartości

Nadawca, który generuje wiadomość zawierającą treść ładunku, POWINIEN
wygenerować pole nagłówka Content-Type w tej wiadomości, chyba że
zamierzony typ nośnika załączonej reprezentacji jest nieznany
nadawcy.

Ta sekcja wyraźnie mówi, abyś to pominął, jeśli nie wiesz tego na pewno. Mówi również, że odbiornik może założyć, że typ to application / octet-stream, ale rzecz jest taka, że może to być również coś innego.

Co zatem jest innego?

RFC-2046
4.5.1. Podtyp strumienia oktetu

Zalecanym działaniem dla implementacji, która otrzymuje jednostkę
„application / octet-stream”, jest po prostu zaoferowanie umieszczenia danych
w pliku z cofniętym kodowaniem Content-Transfer-Encoding lub może
użycie ich jako danych wejściowych dla określonego przez użytkownika proces.

Jak już wspomniano powyżej:

RFC-7231
3.1.1.5. Typ zawartości

Jeśli pole nagłówka Content-Type nie jest obecne, odbiorca MOŻE albo przyjąć typ mediów „application / octet-stream”
([RFC2046], Rozdział 4.5.1), albo sprawdzić dane w celu określenia ich typu.

Wniosek:

Jeśli zdefiniujesz go jako „application / octet-stream”, to mówisz, że wiesz, że jest to „application / octet-stream”.

Jeśli tego nie zdefiniujesz, mówisz, że nie wiesz, co to jest i pozostawiasz decyzję odbiorcy, a odbiorca może sprawdzić, czy chodzi jak kaczka i ...

Sampo Sarrala - codidact.org
źródło

Ta odpowiedź zasługuje na pochwałę, ponieważ jest jedyną prawdą. Dodatkowo, używając domyślnie „strumienia aplikacji / oktetu”, większość przeglądarek wyzwala pobieranie, co jest luką w zabezpieczeniach, biorąc pod uwagę prawie niewidoczne współczesne menedżery pobierania.

FF_Dev

Jest to poprawne w przypadku HTTP, ale pytanie dotyczy ogólnie MIME, a nie HTTP. Na przykład w przypadku poczty elektronicznej zasady są zupełnie inne. Zobacz także dyskusję na proponowanym duplicate stackoverflow.com/questions/12539058/ ...

tripleee

Z tego samego powodu zrezygnowałem, jednak zgadzam się z FF_Dev. O ile intencją nie jest „aplikacja / strumień oktetu” i wyzwalanie pobierania, istnieje potrzeba określenia „aplikacja / nieznane”. Byłoby miło, gdyby przeglądarki nie próbowały pobrać pliku, gdyby nie ustawiono „Dyspozycji treści”, ale jest zbyt wiele witryn internetowych, które przypadkowo pobierają pliki bez ustawiania ich nazwy do użycia. Zwłaszcza banki.

justdan23

Wolę application/unknown, ale wynik na pewno będzie taki sam jakapplication/octet-stream

Lada
źródło

Czy istnieje standard, który pozwala na użycie application / unknown zamiast application / octet-stream?

Hendrik Brummermann

Dzięki! aplikacja / nieznana działa świetnie, strumień oktetu powoduje błąd w przeglądarce Chrome w moim przykładowym pliku png!

fnkr

Po co udostępniać plik .png jako application/octet-streamlub application/unknown? Jest powód, dla którego wymyślili image/png.

Aidiakapi

@ jenson-button-event Nie ma to nic wspólnego z odkrywaniem koła na nowo. Typ MIME określa twój zamiar. Jeśli wiesz, że to, co wysyłasz, ma być obrazem png, przekaż te informacje. Jeśli bajty przypadkowo reprezentują jpeg, aplikacja może Cię ostrzec, że nie jest to prawidłowy plik png i że gdzie indziej masz błąd. Ponadto nie wszystkie aplikacje są tak solidne i odporne na błędy jak przeglądarka. Zostały zaprojektowane, aby naprawić błędy programisty, ale nie jest to jedyny cel. Przeglądarka nie jest jedyną aplikacją używającą typów MIME.

Aidiakapi

Jakie jest twoje odniesienie? nieznany typ nie dostarcza żadnych informacji dotyczących zawartości lub stanu pliku, a nawet jeśli jest binarny lub oparty na tekście, jest zbyt niejasny dla kodu produkcyjnego, może być w porządku dla małego projektu, ponieważ jeśli typ MIME pliku nie ma handler w systemie operacyjnym, jest to zasadniczo plik binarny do pobrania, a nieznany typ to znany uchwyt w systemie operacyjnym Windows, do którego można przypisać akcję (na przykład otwieranie nieznanych plików za pomocą notatnika). Chociaż jest to zła praktyka, możesz użyć nieznanego typu w połączeniu z tym, aby pominąć jakiekolwiek wykonywanie: /