Re: Manifest MIME type (detailed review of Offline Web applications)

On Wed, 3 Oct 2007, Simon Pieters wrote:
> 
> The spec says:
> 
>    Manifests must be served using the text/cache-manifest MIME type.
> 
> What is the advantage of using text/cache-manifest over text/plain?

The main advantage is that it allows us to detect when the remote server 
is actually a captive portal, and allows us to abort in those cases.


> I think using text/cache-manifest has the following problems:
> 
>    * Servers don't have a file extension that maps to text/cache-manifest,
>      so manifests are likely to end up being mislabeled as text/plain or
>      text/html, which in turn makes browsers that ignore the Content-Type
>      work with more content than browsers that honor it. (This is also why
>      it would be a bad idea to introduce a new MIME type for XBL.)

Indeed if browsers do ignore the MIME type this could be a problem, and if 
they do, then we'll have to strip this part of the spec, and we lose the 
advantages (such as captive portal detection). But with luck, and testing, 
and the current expliciteness of the specification, we might avoid this 
problem. (In reality, the spec uses magic signature detection as a 
fallback to the MIME type, so this wouldn't totally break the feature.)


>    * If you try to view a manifest in a browser, then if it was
>      text/cache-manifest existing browsers will promt the user to download
>      the file instead of just viewing it directly. This is not a biggie but
>      sucks for Web app developers and might make them to rather label
>      manifests as text/plain.

True. Browsers really should just support text/* as viewable, as per the 
relevant RFCs.


On Wed, 3 Oct 2007, Mark Baker wrote:
> >
> > What is the advantage of using text/cache-manifest over text/plain?
> 
> Because the text/plain specification doesn't reference the HTML 5 
> specification.

That's not really an advantage, per se, but it is another reason to avoid 
the use of text/plain.


> > I think using text/cache-manifest has the following problems:
> >
> >    * Servers don't have a file extension that maps to text/cache-manifest,
> >      so manifests are likely to end up being mislabeled as text/plain or
> >      text/html, which in turn makes browsers that ignore the Content-Type
> >      work with more content than browsers that honor it. (This is also why
> >      it would be a bad idea to introduce a new MIME type for XBL.)
> 
> By that reasoning, we better just stop with new media types altogether.  
> Freeze the registry! 8-P

I have been suggesting that for a while. :-)


> The Apache mime.types file is kept up to date with the IANA media type 
> registry, and is used to seed many Web servers.  It is indeed possible 
> to roll out new media types over time.

Yeah, we should start the process for updating the registry as soon as we 
are sure that this section of the spec is stable. Any volunteers?


> >    * If you try to view a manifest in a browser, then if it was
> >      text/cache-manifest existing browsers will promt the user to download
> >      the file instead of just viewing it directly. This is not a biggie but
> >      sucks for Web app developers and might make them to rather label
> >      manifests as text/plain.
> 
> That's silly behaviour.  User agents are licensed to interpret unknown 
> text/* types as text/plain, so I see no reason for a "save as" dialog.

I think Simon's point was about current practice, not licensed practice. 
Whether it's silly or not really isn't relevant. :-)


> More importantly though, I don't expect many folks will be clicking on 
> links to cache manifests.

I can certainly see developers looking at manifests just like they look at 
style sheets today. (I do that quite often, e.g.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 11 October 2007 00:27:39 UTC