Open tsmethurst opened 2 days ago
Oh, I sort of see what's happening, so we rely on this file: https://raw.githubusercontent.com/micnic/mime.json/master/index.json for the MIME types, which comes from here: https://github.com/micnic/mime.json, which flattens it into a simple key/value list using the code here: https://github.com/micnic/mime.json/blob/43e72375273ae9d105b733e96a8f71ee3d51d025/build.mjs#L15-L37. All of that originates from the fuller list in a different repo here: https://raw.githubusercontent.com/jshttp/mime-db/refs/heads/master/db.json
From what I can tell then it's basically an accident that we end up with x-m4a
because the micnic build code mentioned above just takes the last value in the source json from jshttp/mime-db, which happens to be nginx's audio/x-m4a
, and uses that as the only value in the resulting key/value list. The arguably more correct IANA version earlier in the jshttp/mime-db list (audio/mp4
) gets overwritten.
I think to fix this, we might want to redo the code generation in gruf/go-mimetypes to draw from https://raw.githubusercontent.com/jshttp/mime-db/refs/heads/master/db.json instead, and prefer (in order) IANA, then Apache, then Nginx when assembling a canonical list of mime types to file extensions.
V. not urgent though, just to clarify -- it's not causing any immediate big problems afaict.
Right now we use the
x-m4a
extension MIME type, but I thinkaudio/mp4
might cause a bit less confusion for browsers and other fedi servers.Reference: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Containers#browser_compatibility