Tipo de archivo desconocido MIME?

140

¿Tengo que especificar un tipo MIME si el archivo cargado no tiene extensión? En otras palabras, ¿hay un tipo MIME general predeterminado?

mime mime-types default-value Shimmy Weitzhandler
fuente

Respuestas:

184

Puede usar application/octet-streampara tipos desconocidos.

RFC 2046 establece en la sección 4.5.1:

El subtipo "octeto-flujo" se usa para indicar que un cuerpo contiene datos binarios arbitrarios.

Bombe
fuente

En realidad, según los RFC, no debe enviar ningún tipo de información con datos desconocidos. RFC-2046 define solo los tipos conocidos, pero RFC-7231 le indica cómo manejar tipos desconocidos.

Sampo Sarrala - codidact.org

@SampoSarrala Leí RFC-7231 de forma un poco diferente: "Si no hay un campo de encabezado de tipo de contenido, el destinatario PUEDE asumir un tipo de medio de" aplicación / flujo de octetos "([RFC2046], Sección 4.5.1) o examinar los datos para determinar su tipo ". Interpreto que, ya que no deberíamos enviar NINGÚN tipo de contenido o estamos seguros de enviar la aplicación / flujo de octetos por defecto si no queremos que los clientes jueguen juegos de adivinanzas con examen de contenido.

Jpnh

@Jpnh Sí, eso es correcto. El encabezado Content-Type no debe estar presente cuando sea desconocido. También se podría enviar la aplicación / octeto-flujo que básicamente le dice al cliente que " no desea mostrarlo en este momento, pero continúe y guarde estos bytes en el archivo ". Esto hace que los clientes web ofrezcan guardar el archivo. Opción 1 == No sé nada sobre este archivo. Opción 2 == El contenido del archivo no se puede describir con mime o solo se debe guardar en el disco. En la práctica, cualquiera de las dos opciones sería correcta. Debería haber elegido una mejor redacción para evitar confusiones.

Sampo Sarrala - codidact.org

Los "datos binarios arbitrarios" no son "desconocidos". Al usar application / octet-stream le dice al navegador que el tipo de contenido es conocido, no es texto ni imagen, sino datos binarios arbitrarios y, como resultado, debe descargarse al archivo y posiblemente ejecutarse. Además de estar equivocado, este es un agujero de seguridad, especialmente considerando los administradores de descargas modernos apenas visibles. La respuesta correcta no es un encabezado de tipo contenido. Si no sabe qué tipo de archivo es, el navegador puede saberlo, así que déjelo adivinar, especialmente cuando conoce el contexto de uso (imagen, documento, script, ...)

FF_Dev

@FF_Dev Estoy seguro de que eso no tiene sentido. "Datos binarios arbitrarios" no implica "ejecutable"; no hay razón para que un navegador (o administrador de descargas) asuma que un application/octet-streamarchivo es ejecutable. E incluso si un navegador está descargando a sabiendas un archivo ejecutable, no "posiblemente lo ejecute" sin que el usuario lo solicite; simplemente descargar un ejecutable no implica que quiera que se ejecute ahora. Si realmente hay un navegador que puede ejecutar application/octet-streamarchivos automáticamente al descargar, díganos cuál y cómo reproducir el comportamiento. Ahora mismo no te creo.

Mark Amery

Recursos de RFC:

Deberíamos usar RFC-7231 (Semántica y contenido HTTP / 1.1) como referencia en lugar de RFC-2046 (Tipos de medios) porque la pregunta era claramente acerca del Tipo de contenido HTTP.

Además, RFC-2046 no define claramente los tipos desconocidos, pero RFC-7231 sí.

Respuesta corta:

No envíe el tipo MIME para datos desconocidos.
Para ser más claro: no utilice el encabezado Content-Type en absoluto.

Referencias

RFC-7231
Protocolo de transferencia de hipertexto (HTTP / 1.1): semántica y contenido
3.1.1.5. Tipo de contenido

Un remitente que genera un mensaje que contiene un cuerpo de carga DEBE
generar un campo de encabezado de tipo de contenido en ese mensaje a menos
que el
remitente desconozca el tipo de medio deseado de la representación adjunta .

Esa sección le dice claramente que lo deje de lado si no lo sabe con certeza. También dice que el receptor podría asumir que ese tipo es application / octet-stream, pero la cosa es que también podría ser otra cosa.

¿Qué es diferente entonces?

RFC-2046
4.5.1. Subtipo Octet-Stream

La acción recomendada para una implementación que recibe una
entidad de "aplicación / flujo de octetos" es simplemente ofrecer poner los datos
en un archivo, con cualquier codificación de transferencia de contenido deshecha, o tal vez
usarlo como entrada para un usuario especificado proceso.

Y, como ya se dijo anteriormente:

RFC-7231
3.1.1.5. Tipo de contenido

Si un campo de encabezado de tipo de contenido no está presente, el destinatario PUEDE asumir un tipo de medio de "aplicación / flujo de octetos"
([RFC2046], sección 4.5.1) o examinar los datos para determinar su tipo.

Conclusión:

Si lo define como "aplicación / octeto-flujo", entonces está diciendo que sabe que es "aplicación / octeto-flujo".

Si no lo define, entonces está diciendo que no sabe qué es y deja la decisión al receptor y el receptor podría verificar si camina como un pato y ...

Sampo Sarrala - codidact.org
fuente

Esta respuesta merece un voto positivo, ya que es la única en la verdad. Además, el uso de "application / octet-stream" de forma predeterminada hace que la mayoría de las descargas del navegador se activen, lo que es un agujero de seguridad considerando los gestores de descargas modernos casi invisibles.

FF_Dev

Esto es correcto para HTTP, pero la pregunta es sobre MIME en general, no sobre HTTP. En el correo electrónico, por ejemplo, las reglas son completamente diferentes. Vea también la discusión en el duplicado propuesto stackoverflow.com/questions/12539058/…

tripleee

Di un aumento por la misma razón, sin embargo, estoy de acuerdo con FF_Dev. A menos que la intención sea ser "aplicación / flujo de octetos" y desencadenar una descarga, existe la necesidad de "aplicación / desconocido". Sería bueno si los navegadores no intentaran descargar el archivo si no se configuró la "Disposición de contenido", pero hay demasiados sitios web que descargan archivos al azar sin configurar su nombre de archivo para usar. Especialmente bancos.

justdan23

Prefiero application/unknown, pero el resultado será seguramente el mismo queapplication/octet-stream

Lada
fuente

¿Existe un estándar que permita usar application / unknown en lugar de application / octet-stream?

Hendrik Brummermann

¡Gracias! application / unknown está funcionando muy bien, ¡octet-stream produce un error en Chrome en mi archivo png de muestra!

fnkr

¿Por qué servir un archivo .png como application/octet-streamo application/unknown? Hay una razón por la que inventaron image/png.

Aidiakapi

@ jenson-button-event No tiene nada que ver con reinventar la rueda. El tipo MIME especifica su intención. Si sabe que se supone que lo que está enviando es una imagen png, pase esa información. Si los bytes representan accidentalmente un archivo JPEG, su aplicación puede advertirle que no es un png válido y que tiene un error en otro lugar. Además, no todas las aplicaciones son tan robustas y tolerantes a fallas como un navegador. Están diseñados para corregir los errores del programador, pero eso no está cerca de su único propósito. Un navegador no es la única aplicación que usa tipos MIME.

Aidiakapi

Cual es tu referencia el tipo desconocido no aporta ninguna información sobre el contenido o el estado del archivo, o incluso si es binario o basado en texto, es demasiado oscuro para el código de producción, podría estar bien para un proyecto pequeño, ya que si un archivo mimetype no tiene controlador en el sistema operativo, es esencialmente un binario descargable, y el tipo desconocido es un controlador conocido en el sistema operativo Windows, al que puede asignar una acción (por ejemplo, abrir archivos desconocidos con el bloc de notas). Aunque es una mala práctica, puede usar el tipo desconocido combinado con esto para omitir cualquier ejecución: /