Re: [widgets] Content-Type Processing Model

Hi Marcos,

On Fri, Jan 30, 2009 at 8:17 AM, Marcos Caceres
<marcosscaceres@gmail.com> wrote:
> As our Widget packaging
> spec [2] has some dependency on content sniffing, we would like to
> contribute to this specification where possible.

Great!  Currently, the draft is optimized for resources retrieved over
HTTP.  In particular, it balances the concerns of compatibility with
existing web content with the security risks posed by servers that let
users upload content.  It seems like widgets have neither of those
constraints, so the draft might not be optimized exactly for your use
case.

> Particularly, we
> would like to make sure that sniffing and appropriate MIME mappings
> are made when resources are read from local storage.

Forgive my ignorance of widgets, but what is local storage?

> At the moment, [1] reads:
>
> " For resources fetched from the file system, user agents should use
>  platform-specific conventions, e.g. operating system extension/type
>  mappings."
>
> We are concerned that operating system extension/type mappings might
> cause issues for widget engines because those mapping could be
> incorrect, or come from arbitrary sources etc.

We have the above text so that users that point their browsers at
their own file systems get types that are consistent with the types
they get by looking at the files in Windows Explorer or the Finder,
etc.  I wouldn't think that widgets would trigger this clause, just as
HTTP resources fetched from a disk cache don't trigger it.

> So we are looking to
> collaborate to resolve this issue and wondering if that can be
> standardized as part of [1]. Our current approach in [2] has been to
> provide a table with a bunch of file extension to MIME mappings.

Why is the magic number approach in sufficient?

Adam

Received on Friday, 30 January 2009 18:52:09 UTC