Skip to content
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

Default Content-Type should be application/octet-stream #14

Open
waylan opened this issue Sep 1, 2016 · 0 comments
Open

Default Content-Type should be application/octet-stream #14

waylan opened this issue Sep 1, 2016 · 0 comments

Comments

@waylan
Copy link

waylan commented Sep 1, 2016

The default fallback Content-Type is currently text/plain. However, is should be application/octet-stream. In fact, RFC 2046 states in section 4.5.1:

The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data.

Additionally, the standard library http.server.SimpleHTTPRequestHandler uses application/octet-stream as the default fallback (as does Tornado and various other third-party static file servers). Interestingly, the standard library http.server.SimpleHTTPRequestHander adds a few custom types defined as text/plain for those few cases were undefined types might actually need to be served as text/plain.

However, in most cases, application/octet-stream is a better fallback. In fact, I have personally encountered the following file types which fail to be properly handled by a browser if not served by either their correct Content-Type or the application/octet-stream fallback.

File Extension Expected Content-Type Acceptable Fallback
.woff2 font/woff2 application/octet-stream
.woff font/woff or application/font-woff application/octet-stream
.ttf font/ttf application/octet-stream
.mustache text/template application/octet-stream
.json application/json application/octet-stream

In each case, the standard mimetypes library fails to return a proper type on Windows. By default, the mimetypes library uses the types as defined by the OS. Therefore, the results can be different from machine to machine and no given type can be guaranteed to be defined on any given system. While some of the above file types would seem to be common (particularly .json), with the great diversity out there, that assumption should not be made.

For the above reason, the Whitenoise static server library (which also uses application/octet-stream as the default fallback) defines their own Content-Types with the following comment in their code:

We use our own set of default media types rather than the system-supplied
ones. This ensures consistent media type behaviour across varied
environments. The defaults are based on those shipped with nginx, with
some custom additions.

Those custom additions are here. I have to wonder if it would make sense for Static to do the same. Regardless, the default fallback should be application/octet-stream, or at the very least, be easily overridable by the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant