Issues with MIME types

Abierto
#170 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
html
Área
web-dev

Línea de trabajo

Comienza revisando las definiciones de File API para el atributo type de Blob y las issues vinculadas de MIME Sniffing y HTML. Compara los requisitos actuales para el análisis MIME, la serialización, el uso de mayúsculas y minúsculas y los valores no ASCII; el trabajo estará terminado cuando las especificaciones afectadas tengan una resolución acordada y coherente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

As part of my work on defining the multipart/form-data parser, I noticed a couple things in the File API standard related to MIME types:

  • The MIME Sniffing standard's "parsable MIME type" definition is no longer present. It was removed as part of whatwg/mimesniff#36.
  • Blob's type attribute is defined as an ASCII string, perhaps assuming that every string that would be successfully parsed as a MIME type, as well as every serialization of a MIME type, would be ASCII strings. This is not the case, as per whatwg/mimesniff#141.
  • Blob's type attribute is also defined as being lowercase. And while the MIME parsing algorithm does ASCII-lowercase the MIME record's type, subtype, and parameter names, it doesn't lowercase parameter values. See whatwg/html#6251 for a case where it matters.

The second point implies that on a response coming from the fetch API that for whatever reason happened to have the MIME type multipart/form-data; boundary=cadena-de-separación (notice the ó), response.formData() might succeed but response.blob() would fail, which would seem paradoxical.

The third point implies that if, for whatever reason, there was a response coming from the fetch API which contained an actual multipart/form-data payload coming from Chromium or WebKit (since they start their boundary strings with WebKitFormBoundary), and a developer decoded it as a Blob; trying to parse that blob afterwards with new Request(blob).formData() would fail, since the boundary string seems to be parsed case-sensitively.

Lenguaje dominante
HTML
Estrellas
118
Forks
52
Merge medio
9 d 16 h
PR fusionados (30 d)
1

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de w3c/FileAPI

Todos los issues de w3c/FileAPI

Issues similares

Más issues de Web Dev

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.