c# - Why does FindMimeFromData recognize image/tiff on one host, but doesn't on another one? -

c# - Why does FindMimeFromData recognize image/tiff on one host, but doesn't on another one? -

i'm using findmimefromdata urlmon.dll sniffing uploaded files' mime type. according mime type detection in net explorer, image/tiff 1 of recognized mime types. works fine on development machine (windows 7 64bit, ie9), doesn't work on test env (windows server 2003 r2 64bit, ie8) - returns application/octet-stream instead of image/tiff.

the above article describes exact steps taken determine mime type, since image/tiff 1 of 26 recognized types, should end on step 2 (sniffing actual data), file extensions , registered applications (and other registry stuff) shouldn't matter.

oh , way, tiff files are associated programme (windows image , fax viewer) on test server. it's not reference tiff absent in windows registry.

any ideas why doesn't work expected?

edit: findmimefromdata used this:

public class mimeutil { [dllimport("urlmon.dll", charset = charset.unicode, exactspelling = true, setlasterror = false)] private static extern int findmimefromdata( intptr pbc, [marshalas(unmanagedtype.lpwstr)] string pwzurl, [marshalas(unmanagedtype.lparray, arraysubtype = unmanagedtype.i1, sizeparamindex = 3)] byte[] pbuffer, int cbsize, [marshalas(unmanagedtype.lpwstr)] string pwzmimeproposed, int dwmimeflags, out intptr ppwzmimeout, int dwreserved); public static string getmimefromdata(byte[] data) { intptr mimetype = intptr.zero; seek { const int flags = 0x20; // fmfd_returnupdatedimgmimes int res = findmimefromdata(intptr.zero, null, data, data.length, null, flags, out mimetype, 0); switch (res) { case 0: string mime = marshal.ptrtostringuni(mimetype); homecoming mime; // snip - error handling // ... default: throw new exception("unexpected hresult " + res + " returned findmimefromdata (in urlmon.dll)"); } } { if (mimetype != intptr.zero) marshal.freecotaskmem(mimetype); } } }

which called this:

protected void uploader_fileuploaded(object sender, fileuploadedeventargs e) { int bsize = math.min(e.file.contentlength, 256); byte[] buffer = new byte[bsize]; int nbytes = e.file.inputstream.read(buffer, 0, bsize); if (nbytes > 0) string mime = mimeutil.getmimefromdata(buffer); // ... }

i unable reproduce problem, did research on subject. believe suspect, problem step 2 of mime type detection: hard-coded tests in urlmon.dll v9 differ in urlmon.dll v8.

the wikipedia article on tiff shows how complex format , has been problem beginning:

when tiff introduced, extensibility provoked compatibility problems. flexibility in encoding gave rising joke tiff stands thousands of incompatible file formats.

the tiff compression tag section shows many rare compression schemes that, suspect, have been omitted while creating urlmon.dll hard-coded tests in before versions of ie.

so, can done solve problem? can think of 3 solutions, each of them brings different kind of new problems along:

update ie on dev machine version 9. apply latest ie 8 updates on dev machine. known modified versions of urlmon.dll introduced (eg. kb974455). 1 of them may contain updated mime hard-coded tests. distribute own re-create of urlmon.dll application.

it seems solutions 1 , 2 ones should take from. there may problem, however, production environment. experience shows administrators of production env disagree install updates many reasons. may harder convince admin update ie v9 , easier install ie8 kb update (as supposed to, know how is). if you're in command of production env, think should go solution 1.

the 3rd solution introduces 2 problems:

legal: may against microsoft's policies distribute own re-create of urlmon.dll coding: have load the dll dynamically phone call findmimefromdata function or @ to the lowest degree customize app's manifest file because of dynamic-link library search order. assume aware, bad thought manually re-create newer version of urlmon.dll scheme folder other apps crash using it.

anyway, luck solving urlmon riddle.

c# winapi mime-types mime urlmon