-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: mime: expand on what is covered by builtinTypes #69530
Comments
what's included is based on WHATWG mime sniffing |
@seankhliao Wow, thanks for the quick response, but I'm confused as to where that actually specifies specifically just the mime types specified in builtinTypes. From my understanding that would be more relevant for |
Simply implements the first recommended type for each file extension listed in MDN https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types However, this excludes ".3gp" and ".3gp2" as from from I can tell it is not possible to know if it is video or audio solely from file extension. As far as I can tell there are two previous PRs that each implemented a type simply because they were in common use. Updates golang#69530
Change https://go.dev/cl/614376 mentions this issue: |
Related Issues and Documentation (Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
Comment with the source of the builtin types Updates golang#69530
net/http.DetectContentType is based on WHATWG's spec; this proposal is for the type/extension mapping used by mime.TypeByExtension and other functions in the mime package when the system MIME database (/etc/mime.types or similar) isn't present. |
Per conversation here whatwg/mimesniff#51 (comment), the intent of the Mimesniff spec is "Based on the recent trajectory of changes to this spec, it seems to me that the scope of the spec is client-side sniffing for cross-browser compatibility and protection for the user against malicious files" Mimesniff spec is not an appropriate spec for a http server use case. It would be better to adopt a different spec for this. Alternatively, a new function that is server side appropriate that implements a different spec is needed. (EDIT: This comment was regarding DetectContentType, not TypeByExtension) |
@milhoan But as of now, this doesn't mimesniff. It just maps file extensions to mime types |
Sorry, I saw the discussion above about DetectContentType being based on that spec(imo it should not be). Disregard my comment as this is not about that function. I'm 100% in favor of more mime type coverage for TypeByExtension |
Looking at what the browsers do for matching file extensions to mime type: Chromium https://chromium.googlesource.com/chromium/src/+/master/net/base/mime_util.cc#129 Firefox https://searchfox.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2968 Below is a table mapping file extensions to go mime types and chromium / firefox inclusion in primary (1) or secondary (2) lists, and their mime type if it differs from what go has.
|
If we are to add more, I propose we limit it to what both browsers have decided to include in their built in lists. |
That sounds good to me, I can update the PR if that is what's decided on |
Proposal Details
Right now,
mime/type.go includes what seems to be a somewhat arbitrary list of built-in types:
I think some guidance on what should be included in this would be good, rather than a consumer of the package not realizing there are arbitrary gaps. In the meantime I will submit a PR that will incorporate all MDN defined "Common Types" (which also I have to admit is arbitrary, but at least covers more common usecases.)
The text was updated successfully, but these errors were encountered: