You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.SimpleHTTPRequestHanderadds 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.
The text was updated successfully, but these errors were encountered:
The default fallback Content-Type is currently
text/plain
. However, is should beapplication/octet-stream
. In fact, RFC 2046 states in section 4.5.1:Additionally, the standard library
http.server.SimpleHTTPRequestHandler
usesapplication/octet-stream
as the default fallback (as does Tornado and various other third-party static file servers). Interestingly, the standard libraryhttp.server.SimpleHTTPRequestHander
adds a few custom types defined astext/plain
for those few cases were undefined types might actually need to be served astext/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 theapplication/octet-stream
fallback..woff2
font/woff2
application/octet-stream
.woff
font/woff
orapplication/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, themimetypes
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: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.The text was updated successfully, but these errors were encountered: