http/file-server, media_types: new addition application/mp4 to mime db overrides video/mp4 and breaks some net players

[NaitLee]

Describe the bug
New addition application/mp4 to media_types/vendor/db.ts (#2286) overrides video/mp4 for the contentType function. As file-server specifies content-type by that function and the db, it breaks some network-capable video players which expecting the mimetype to be video/*, because the received mimetype application/mp4 is unexpected, they won't play the video anymore

Steps to Reproduce

1. Start newest file-server inside a folder with some mp4

$ deno run --allow-read --allow-net --allow-sys jsr:@std/[email protected]/file-server
Listening on:
- Local: http://localhost:8000
- Network: http://192.168.2.103:8000

2. Issue a HEAD request to any video:

$ curl --head http://localhost:8000/1.mp4
HTTP/1.1 200 OK
...
content-type: application/mp4
...

3. The content-type is the new addition application/mp4, as it wins video/mp4. This breaks some network players as stated, as they don't identify application/mp4; they only know about video/mp4

Expected behavior

1. Start an older version of file-server, without the mimetype update

$ deno run --allow-read --allow-net --allow-sys jsr:@std/[email protected]/file-server
Listening on:
- Local: http://localhost:4507
- Network: http://192.168.2.103:4507

2. Issue a HEAD request to any video:

$ curl --head http://localhost:4507/1.mp4
HTTP/1.1 200 OK
...
content-type: video/mp4
...

3. as the mimetype video/mp4 is by far the most preferred, it always worked for most (if not all) network players

Environment

• OS: any
• deno version: 1.45.2
• std version:
  • @std/media_types after the commit 6d58a57
  • @std/http 0.224.1 and above

P.S.

I think we need a smarter contentType function or mimetypes db that has preference over the "best" mimetype for certain file extensions. I see a similar problem had happened on application/javascript over text/javascript (#5186), probably there are far more media types are affected.

Likely that most players affected by this are proprietary, so fixing all the players is not feasible.

[iuioiua]

Thank you for testing @std/[email protected] out. This bug should be addressed before stabilization.

Currently, the value of the content-type header is determined from the extension in the URL. Instead, we should gather all possible content-types for a given extension (i.e. something like a version of contentType that returns an array of possible content-types instead of just one), then use accepts to determine the most appropriate content-type, based on the client's request.

Any thoughts, @kitsonk?

[kt3k]

Looks like this is affected by this change in the upstream jshttp/mime-db@48e4115

[kt3k]

@NaitLee Do you know if those players send accept headers when requesting mp4 files?

[kt3k]

I think we should just return video/mp4 for contentType(".mp4") (and typeByExtension(".mp4")) by defining our preference in media_types/_db.ts.

[kt3k]

See also https://stackoverflow.com/questions/9929940/correct-mime-type-for-mp4

[NaitLee]

@NaitLee Do you know if those players send accept headers when requesting mp4 files?

in my test, none of android vlc, mpv, and other numerous players i've tested send accepts header.

i'm wondering if application/x is always "the least prefered type" if other types like video/x or text/x are around. if that's the case just prefer those over application/x one.

in my mind the preference can be video > audio > image > text > application, it's at least correct for mp4, ogg, svg, and javascript, probably ok for .ts too.

[kt3k]

Looks like there's a line that implements the preference of application/* types over other types

std/media_types/_db.ts

Line 37 in 702f048

(from === to && current.startsWith("application/")))

The line exists from the beginning of the package: https://github.com/denoland/std/pull/2286/files#diff-92e0917a6de42a1319f4f29e026ba39b73bf1dc70dececdcbced2d732b018d99R60