2012-03-12 22 views
9

Estoy escribiendo una API de aplicación web, donde cuando alguien accede a una URL, devuelve datos de texto. Establecí el tipo de contenido en "texto/normal", pero cuando accedo a él con Chrome, descarga un archivo que contiene la información, en lugar de mostrarlo. Cuando accedo a él con IE, se muestra correctamente, y cuando accedo con Firefox, dice que está intentando acceder a una aplicación/octet-stream y me pregunta si deseo descargar el archivo.content-type of text-plain hace que el navegador descargue el archivo

que registran lo que estaba siendo devuelto por el servidor web utilizando TinyHTTPProxy, y es como sigue:

[2012-03-11 16:51:45.345] INFO  {TinyHTTPProxy Thread-4} HTTP/1.1 200 OK 
Content-Type: text/plain 
Transfer-Encoding: chunked 
Connection: close 
Date: Mon, 05 Mar 2012 09:49:54 GMT 
Server: localhost 


[2012-03-11 16:51:45.345] INFO  {TinyHTTPProxy Thread-4} 10b 
P,FIO,7,31.5900,0.,,0,100,0,0,30.7600,31.9600,100,1000,,,0.,16:03:14t,,0,31.5900 ,1.2,,,15,n,,,,,03/09/2012,,31.2200,,,,-0.37,-0.37,0.274456994,,,,,0,,2846732.85 ,14,4,,3989502,BSE-CSE-NYSE-PSE-NMS,,,,,0,,,0,1155872,N,,26,26,26,16:03:14,5-7-10-11-12-13-18-25-26-28-80,0 

Si cambio el tipo de contenido "application-json", entonces se muestra en todos los navegadores. Además, si cambio el tipo de contenido a "text/html", también funciona, aunque no devuelvo un archivo HTML.

¿Existe alguna explicación de por qué text/plain se comporta de esta manera? Revisé para asegurarme de que todos los datos devueltos son realmente ASCII, y dado que estoy configurando el tipo de contenido como texto/normal, estoy confundido por qué se está interpretando como application/octet-stream.

Respuesta

7

Parece que se está ejecutando en Chrome Issue 106150. Chrome aparentemente (a veces) decide usar la lógica "sniffing" cuando el tipo de contenido es text/plain.

soluciones posibles:

  • Si el texto es Unicode, incluyen una lista de materiales. Esto le dirá a la lógica de oler que realmente es texto.
  • Elimina los bytes de "aspecto binario" del archivo. Del informe de errores "Cualquier valor entre 0x00 y 0x1f se ve como binario excepto para ESC, CR, NP, NL, HT".
  • Parece que usar una extensión que se supone que es text/plain (como .txt) podría desactivar el sniffing.
+0

Interesante, gracias por la información, no me di cuenta de que los navegadores olfatearían los datos para tratar de hacer algo más inteligente. – steve8918

+0

Gracias por esto. Estaba tratando de entender por qué Chrome insiste en descargar un archivo de texto/normal UTF-8, y resulta que hubo dos instancias de 0x02 en él. – dgw

+0

Chrome olfatea solo los primeros x bytes (posiblemente 1KB) para bytes de aspecto binario, lo que puede hacer que esto sea impredecible. A veces tenía bytes de aspecto binario en el primer 1KB y algunas veces no lo hacía mientras hacía algunas llamadas print_r de investigación. Consulte la respuesta de @ trinth para la solución del día actual. – thomasrutter

6

La explicación de Laurence es correcta. Solo IE y Chrome están realizando mime sniffing en el momento de esta publicación. ¡Ahora puede configurar el encabezado HTTP X-Content-Type-Options: nosniff y será suficiente!

Cuestiones relacionadas