Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Use stdlib mimetypes instead of hardcoding them.#14218
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
The stdlib provides all necessary mimetypes (see _default_mime_types),except for application/emf -- but we don't have an emf backend anymore.This also makes the dict (relatively) easily extensible by the end user,who could call `mimetypes.init(...)` themselves to add entries to themapping.
| self.set_header('Content-Type', mimetypes.get(fmt, 'binary')) | ||
| self.set_header( | ||
| 'Content-Type', mimetypes.types_map.get(fmt, 'binary')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
The fallback should beapplication/octet-stream, should it not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This PR leaves the old behavior, but I'd say that octet-stream is more correct, indeed.
The stdlib provides all necessary mimetypes (see _default_mime_types),
except for application/emf -- but we don't have an emf backend anymore.
This also makes the dict (relatively) easily extensible by the end user,
who could call
mimetypes.init(...)themselves to add entries to themapping.
PR Summary
PR Checklist