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
mimetypes does not support webm type #60533
Comments
(patch in attachment) |
How do we know if the "webm" file is video+audio or audio only?. Mimetypes are different. :-? |
I'd say we can't but I suppose the same problem might exist for other mime types as well. |
I suppose this is a flaw in the mimetype API. At some point perhaps we should fix it, but in the meantime....does anyone have a pointer to an actual IANA submission for this mime type? I think we can probably no longer wait for official IANA approval, but it would be nice to have some sort of documentation that a given type is more than just in de-facto existence. |
AFAICT, there is currently no entry for WebM in IANA's registry (http://www.iana.org/assignments/media-types/index.html ). Giampaolo has already pointed out the relevant part of the WebM spec. WebM itself has no RFCs (there are 2 relating to VP8, its video codec, but they don't have anything that's relevant here). To independently corroborate the existence of the MIME type, we have the following: Mozilla, Microsoft, and Opera all acknowledge the MIME type in question: The de-facto *nix MIME type database/package maintained by freedesktop.org includes it: |
Interesting. So we have two choices: leave it to the platform mime types file to define because it is not even on track to be an official IANA standard, or include it with a comment that it is a de-facto standard. The question, I guess, is how fluid the definition is likely to be. It doesn't seem like the filetype mapping for the existing definitions is going to change, and since we don't (currently) have content-detection of any sort, the impact of a change in the definitions to users of our code seems minimal. So I guess I'd be OK with adding it as a de-facto standard, though I'm not entirely comfortable with it. But that would represent a change in policy, so others may want to weigh in. |
So, nobody seems to have cared enough about the policy change to weigh in during the intervening year and ~3mos... |
I interpreted Issue 15's closure as being about the distinction between Application/webm vs Video/webm, etc. As far as I understand it, the python stdlib doesn't actually care what the major Mime type is, or, frankly, even whether the definition makes sense. We just want Video/webm to be registered. I have created issue 886 on the webm site at Anyone with more detail (e.g., do we need to define Application/webm as well as Video/webm ... do we care what the definition is ... etc ...) is encouraged to chime in. |
WebM's docs use "video/webm" and never use an "application/*" type. They also specify "audio/webm" for audio-only content, but both use the same file extension, so associating ".webm" with "video/webm" seems quite reasonable since it's more general (an audio-only file is just a degenerate case of an audiovideo file). |
Antoine Pitrou and Ethan Furman agreed on pydev that this should be applied. Chris, is the existing patch exactly what you think is needed? |
Does test_mimetypes (assuming it exists), have a test for the mapping, are is something needed? |
Yes, the existing patch looks fine. |
A while ago there was a discussion about updating the MIME registry on bug fix releases too, and I seem to remember people agreed it should be done. If this is indeed the case and the patch is accepted for 3.5, should it also be backported to 2.7 and 3.4? |
New changeset 0327a5a11108 by Berker Peksag in branch '3.5': New changeset f92e6785b9f0 by Berker Peksag in branch 'default': |
New changeset 6ed3cb699be6 by Berker Peksag in branch '2.7': |
Thanks! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: