Sorry, forgot to attach the test upload file

Deleted: test_file.dwg 106 KB

test_file.dwg 106 KB Download

Tested this issue on Windows 10 with chrome #61.0.3143.0 with provided files in comment #0, #1

Observed after uploading .dwg file, in the console file[0].type is empty.

attaching the screen-shot for reference.

aran@ could you confirm that this is the issue you are facing.

Thank You...

Deleted: Issue 737127.PNG 30.9 KB

	Issue 737127.PNG 30.9 KB View Download

Hi,

Yes, this is indeed the issue. All other file types I could think to test all correctly returned the mime types expected.

To ensure this wasn't simply a bad file, I have downloaded multiple *.dwg files from different sources online and found the results to all be the same (blank string returned).

Many thanks,
Aran

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

May be the same as issue 155455 - if the host operating system doesn't provide a mapping for the type (e.g. the extension is unknown, can't be sniffed, etc), the empty string is used for the type.

We should compare behavior with other browsers and see if they produce 'application/octet-stream' or '' for unknown types.

Firefox has the same behavior - type is empty string if the system can't determine the content type.

On Windows, type resolution is done via the registry (with a very small number of hardcoded fallbacks in Chrome). If you run regedit.exe and look in HKEY_CLASSES_ROOT you'll see entries for known extensions. On my Windows box I don't have an entry for ".dwg" for example, but under e.g. ".avi" there is a key ContentType "video/avi"

Since (1) you can't assume everyone has apps installed locally, and (2) browsers can't map every extension to a content type, and (3) you can't trust extensions due to security concerns, you can't really rely on the content type being meaningful.

Chrome's relevant code is in net/base/mime_util.cc and specifically https://cs.chromium.org/chromium/src/net/base/mime_util.cc?type=cs&l=64 with kPrimaryMappings consulted first, then the operating system (e.g. windows registry), then kSecondaryMappings.

(I've raised this as an interop issue against the File API spec. https://github.com/w3c/FileAPI/issues/51 - maybe we shouldn't even check the operating system, all browsers should hard-code a list, and otherwise return blank.)