Re: [widgets] Content-type sniffing and file extension to MIME mapping

Marcos Caceres wrote:
> Do you have any suggestions as to how we might move forward? Or a
> different approach to solving the problem?

The problem being that a ZIP file doesn't know anything about the types 
of files in it?

What Gecko does right now for jar: URIs is somewhat similar to what it 
does for file: URIs.  Specifically:

1)  If the caller expects a particular type and indicates that, use
     that type.  For example, any jar: URI loaded from a
     <link rel="stylesheet" type="text/css"> will be treated as
     text/css.
2)  If the caller has no type expectation, look up type based on
     extension.  This doesn't use a particular hardcoded list but
     does a best-effort lookup based on a hardcoded override list
     in Gecko, the type+extension combinations the user's profile
     has seen and acted on before, the OS extension to type mappings,
     another hardcoded list of extension-to-type hints (which differ
     from the overrides in not overriding the OS mappings).
3)  If step 2 did not find a type, use our standard unknown content
     sniffer (which sniffs based on various stuff including the URI,
     the data, etc).

None of this is great for interoperability, of course, but it's no worse 
than anything that happens with file:// URIs.

I suppose you could in fact define a small set of extensions that would 
interoperably be mapped to particular types in the context of widgets. 
You could also define a particular file in the package that contains 
extension-to-type mappings (either without the predefined mappings, or 
able to add to and override the predefined mappings).  You'd need 
something like this for sane extensibility anyway, in my opinion.

-Boris

Received on Tuesday, 2 December 2008 18:40:18 UTC