The issue flagged this morning has two dimensions: first, that we don't want to validate MIME types for staff users, and second, that certain uploads were failing for certain unknown file types.
Your fix this morning solved the first, and this PR addresses the second — by falling back to the default application/octet-stream MIME type when the file is otherwise unknown. This way, every upload request is guaranteed to include a Content-Type — and we don't have to worry about conditional handling on conditions array depending on which values are available or not.
Unfortunately the browser File.prototype.type field returns an empty string when it encounters a file it's unfamiliar with, so I had to modify the Fine-Uploader library to support a default value. As in previous edits to this vendored file, I left a note — but since the library is fully deprecated, we won't be able to contribute this fix upstream to the library itself.
The issue flagged this morning has two dimensions: first, that we don't want to validate MIME types for staff users, and second, that certain uploads were failing for certain unknown file types.
Your fix this morning solved the first, and this PR addresses the second — by falling back to the default
application/octet-streamMIME type when the file is otherwise unknown. This way, every upload request is guaranteed to include a Content-Type — and we don't have to worry about conditional handling onconditionsarray depending on which values are available or not.Unfortunately the browser File.prototype.type field returns an empty string when it encounters a file it's unfamiliar with, so I had to modify the Fine-Uploader library to support a default value. As in previous edits to this vendored file, I left a note — but since the library is fully deprecated, we won't be able to contribute this fix upstream to the library itself.