Issues with MIME types

Aperta
#170 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
html
Ambito
web-dev

Direzione di ricerca

Inizia esaminando le definizioni di File API per l’attributo type di Blob e le issue collegate di MIME Sniffing e HTML. Confronta i requisiti attuali per l’analisi MIME, la serializzazione, la distinzione tra maiuscole e minuscole e i valori non ASCII; il lavoro è completato quando le specifiche interessate hanno una risoluzione concordata e coerente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
HTML
Stelle
118
Fork
52
Merge medio
9g 16h
PR unite (30g)
1

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di w3c/FileAPI

Tutte le issue di w3c/FileAPI

Issue simili

Altre issue su Web Dev

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.