Tipo di file sconosciuto MIME?

140

Devo specificare un tipo MIME se il file caricato non ha estensione? In altre parole, esiste un tipo MIME generale predefinito?

mime mime-types default-value

— Shimmy Weitzhandler
fonte

Risposte:

184

È possibile utilizzare application/octet-streamper tipi sconosciuti.

RFC 2046 afferma nella sezione 4.5.1:

Il sottotipo "octet-stream" viene utilizzato per indicare che un corpo contiene dati binari arbitrari.

— Bombe
fonte

In realtà, per RFC non è necessario inviare informazioni di tipo con dati sconosciuti. RFC-2046 definisce solo i tipi noti, ma RFC-7231 spiega come gestire i tipi sconosciuti.

— Sampo Sarrala - codidact.org,

@SampoSarrala Ho letto RFC-7231 in modo leggermente diverso: "Se non è presente un campo di intestazione Content-Type, il destinatario PUO 'assumere un tipo di media di" application / octet-stream "([RFC2046], Sezione 4.5.1) oppure esaminare i dati per determinarne il tipo. " Interpreto che come dovremmo inviare NO Content-Type o siamo sicuri di inviare application / octet-stream come predefinito se non vogliamo che i clienti giochino a indovinare giochi con l'esame del contenuto.

— Jpnh,

@Jpnh Sì, esatto. L'intestazione Content-Type non dovrebbe essere presente ogni volta che è sconosciuta. Si potrebbe anche inviare application / octet-stream che sostanzialmente dice al client che " non si desidera visualizzarlo ora, ma continuare e salvare questi byte su file ". In questo modo i client Web offrono il salvataggio dei file. Opzione 1 == Non so nulla di questo file. Opzione 2 == Il contenuto del file non può essere descritto usando mime o dovrebbe essere salvato solo su disco. In pratica, entrambe le opzioni sarebbero corrette. Avrei dovuto scegliere una formulazione migliore per evitare confusione.

— Sampo Sarrala - codidact.org

"Dati binari arbitrari" non è "sconosciuto". Usando application / octet-stream dici al browser che il tipo di contenuto è noto, non è testo né un'immagine ma dati binari arbitrari e di conseguenza dovrebbe essere scaricato su file ed eventualmente eseguito. Oltre ad essere sbagliato, questo è un buco nella sicurezza, soprattutto considerando i gestori di download moderni appena visibili. La risposta giusta non è un'intestazione del tipo di contenuto. Se non sai che tipo di file è, il browser potrebbe saperlo, quindi lascialo indovinare, soprattutto quando conosceva il contesto di utilizzo (immagine, documento, script, ...)

— FF_Dev

@FF_Dev Sono sicuro che non ha senso. "Dati binari arbitrari" non implica "eseguibile"; non c'è motivo per cui un browser (o download manager) dovrebbe presumere che un application/octet-streamfile sia eseguibile. E anche se un browser sta scaricando consapevolmente un file eseguibile, non "probabilmente lo esegue" senza che l'utente lo chieda; il semplice download di un eseguibile non implica che lo desideri eseguito in questo momento. Se esiste davvero un browser in grado di eseguire application/octet-streamautomaticamente i file durante il download, comunicaci quale e come riprodurre il comportamento. In questo momento non ti credo.

— Mark Amery,

Risorse RFC:

Dovremmo usare RFC-7231 (semantica e contenuto HTTP / 1.1) come riferimento anziché RFC-2046 (tipi di media) perché la domanda era chiaramente sul tipo di contenuto HTTP.

Anche RFC-2046 non definisce chiaramente tipi sconosciuti, ma RFC-7231 lo fa.

Risposta breve:

Non inviare il tipo MIME per dati sconosciuti.
Per essere più chiari: non utilizzare affatto l'intestazione Content-Type.

Riferimenti:

RFC-7231
Hypertext Transfer Protocol (HTTP / 1.1): Semantica e contenuto
3.1.1.5. Tipo di contenuto

Un mittente che genera un messaggio contenente un corpo di payload DOVREBBE
generare un campo di intestazione Content-Type in quel messaggio a meno che il
tipo di supporto previsto della rappresentazione allegata non sia sconosciuto al
mittente.

Quella sezione ti dice chiaramente di lasciarla fuori se non lo conosci per certo. Indica anche che il ricevitore potrebbe presumere che il tipo sia application / octet-stream ma la cosa è che potrebbe anche essere qualcos'altro.

Cosa c'è di diverso allora?

RFC-2046
4.5.1. Sottotipo Octet-Stream

L'azione raccomandata per un'implementazione che riceve
un'entità "application / octet-stream" è semplicemente offrire di mettere i dati
in un file, con qualsiasi codifica di trasferimento di contenuto annullata, o forse di
usarli come input per un utente specificato processi.

E, come già detto sopra:

RFC-7231
3.1.1.5. Tipo di contenuto

Se non è presente un campo di intestazione Content-Type, il destinatario PUO 'assumere un tipo di media di "application / octet-stream"
([RFC2046], Sezione 4.5.1) o esaminare i dati per determinarne il tipo.

Conclusione:

Se lo definisci come "application / octet-stream", allora stai dicendo che sai che è "application / octet-stream".

Se non lo definisci, allora stai dicendo che non sai di cosa si tratta e lascia la decisione al ricevitore e il ricevitore potrebbe quindi verificare se cammina come anatra e ...

— Sampo Sarrala - codidact.org
fonte

Questa risposta merita un voto in quanto è l'unica nella verità. Inoltre, l'utilizzo di "application / octet-stream" per impostazione predefinita rende la maggior parte dei download di trigger del browser che è una falla di sicurezza considerando i moderni gestori di download quasi invisibili.

— FF_Dev

Questo è corretto per HTTP, ma la domanda riguarda MIME in generale, non HTTP. Nell'email, ad esempio, le regole sono completamente diverse. Vedi anche la discussione alla proposta duplicato stackoverflow.com/questions/12539058/...

— tripleee

Ho dato un uptick per lo stesso motivo, tuttavia sono d'accordo con FF_Dev. A meno che l'intento non sia "application / octet-stream" e per attivare un download, è necessario "application / unknown". Sarebbe bello se i browser non provassero a scaricare il file se "Content-Disposition" non fosse impostato, ma ci sono troppi siti Web che scaricano casualmente file senza impostare il loro nome da usare. Soprattutto le banche.

— justdan23,

Preferisco application/unknown, ma il risultato sarà sicuramente lo stesso diapplication/octet-stream

— Lada
fonte

Esiste uno standard che consente di utilizzare application / unknown invece di application / octet-stream?

— Hendrik Brummermann,

Grazie! application / unknown funziona alla grande, octet-stream provoca un errore in chrome nel mio file png di esempio!

— 1313

Perché servire un file .png come application/octet-streamo application/unknown? C'è una ragione per cui hanno inventato image/png.

— Aidiakapi,

@ jenson-button-event Non ha nulla a che fare con il reinventare la ruota. Il tipo MIME specifica il tuo intento. Se sai che ciò che stai inviando dovrebbe essere un'immagine png, passa queste informazioni. Se i byte rappresentano accidentalmente un jpeg, l'applicazione può avvisarti che non è un png valido e che hai un bug da qualche altra parte. Inoltre, non tutte le applicazioni sono robuste e resistenti ai guasti come un browser. Sono progettati per correggere gli errori del programmatore, ma non è affatto vicino al suo unico scopo. Un browser non è l'unica applicazione che utilizza i tipi MIME.

— Aidiakapi,

Qual è il tuo riferimento? il tipo sconosciuto non fornisce alcuna informazione riguardo al contenuto o allo stato del file, o anche se è binario o basato su testo, è troppo oscuro per il codice di produzione, potrebbe essere ok per un piccolo progetto, poiché se un mimetype del file non ha gestore nel sistema operativo, è essenzialmente un file binario scaricabile e il tipo sconosciuto è un handle noto nel sistema operativo Windows, al quale è possibile assegnare un'azione (ad esempio l'apertura di file sconosciuti con il blocco note). Sebbene la cattiva pratica sia possibile utilizzare il tipo sconosciuto combinato con questo per saltare qualsiasi esecuzione: /