javascript - formdata - la información enviada no era un archivo compruebe el tipo de codificación del formulario

El tipo de contenido para la parte de archivo de la solicitud multipart/form-data está configurado incorrectamente por el cliente

Question

Estoy intentando enviar multipart/form-data con los siguientes JavaScript y jQuery:

var formData = new FormData();

formData.append("projectName", $("#projectNameInput").val());

var file = $("#fileInput")[0].files[0];
formData.append("content", file);

var xhr = new XMLHttpRequest();
xhr.open(''POST'', ''/project'', true);
xhr.onload = function(ev) {
  // Handling logic omitted
};
xhr.send(formData);

Sin embargo, algunos navegadores de clientes (Firefox y Chrome) reciben 400 Bad Request del servidor. Al examinar los encabezados y solicitar la carga útil, descubrí que algunos navegadores establecen un tipo de contenido explícito para el archivo de la siguiente manera:

------WebKitFormBoundaryEuDIpEU2Ci8VNwNJ 
Content-Disposition: form-data; name="content"; filename="testfile.ext" 
Content-Type: EXT Project Data (64bit)

------WebKitFormBoundaryEuDIpEU2Ci8VNwNJ

En una solicitud de trabajo, Content-Type debería ser el siguiente: Content-Type: application/octet-stream , que el servidor puede manejar correctamente.

Sospecho que esto tiene algo que ver con la configuración del navegador o las asociaciones de archivos. ¿Hay alguna forma de establecer explícitamente el tipo de contenido para la parte del archivo de la solicitud?

El problema ocurre con algunos usuarios que usan Firefox y Chrome. Sin embargo, algunos usuarios pueden subir de manera exitosa usando Chrome y Firefox. IE no es compatible con nuestra aplicación.

Answer 1

Ok, nos las arreglamos para resolver este problema. Resultó que el tipo de contenido registrado en el sistema cliente estaba realmente mal formado en algunas máquinas cliente, que tenían cierta aplicación de terceros instalada.

No podemos cambiar programáticamente los conjuntos de navegador de tipo de contenido para la pieza. Como Michael-O señaló, siempre debe usar los tipos de contenido registrados en IANA . Aquí hay un enlace al estándar.

En este caso, fue un software de terceros que registró el tipo de contenido ilegal en el sistema del cliente. El tipo de contenido puede no contener espacios en blanco, por lo que el tipo de contenido EXT Project Data es claramente ilegal. Solucionamos el problema cambiando el tipo de contenido registrado a un tipo de contenido personalizado . Entonces, el tipo de contenido que estamos utilizando ahora es application/x-ext-project-data , que luego se maneja correctamente en el lado del servidor.