https://bugzilla.wikimedia.org/show_bug.cgi?id=4421
--- Comment #30 from Robert Rohde <[email protected]> 2009-10-18 17:51:44 UTC --- (In reply to comment #29) > The simplest way to handle this from our perspective is to just give all the > on-disk files a name ending in, say, .png. This will typically cause an > incorrect Content-Type to be served -- except for PNG files, of course -- but > browsers will display the pictures fine anyway, as long as it's served as some > recognized image type. See > <http://tools.ietf.org/html/draft-abarth-mime-sniff-03>. In fact, it should > work fine in many cases even if a non-image MIME type is served. > > Arguably, relying on this MIME type sniffing is incorrect and confusing. But > it's a possibility, for simplicity's sake. It's certainly reliable. Though I haven't tested it systematically, I'll assume that some fraction of browsers will happily process some fraction of file types without extensions. However this feels like a terrible hack, and I worry that not enough browsers would process enough file types. In particular, if we want our approach to work for Mediawiki installs in general, then we can't simply assume that we are only talking about image files. Does it work for PDFs, for Word Documents, for spreadsheets, etc.? Also if the file has a .png extension and a person saves it to their local hard drive, then I strongly suspect that Windows users will have a hard time reading the file in most apps without manually changing the extension (not sure about Mac / Linux). I think it makes much more sense to provide the user with an appropriate extension, even if that information is unnecessary in some cases. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
