Re: review of content type rules by IETF/HTTP community

On Mon, 20 Aug 2007, Sam Ruby wrote:
> > 
> > For what it's worth, I strongly agree with you that (for security 
> > reasons if nothing else!) you should never have text/plain documents 
> > that only use non-<control> characters sniffed and treated like HTML, 
> > RSS, or Atom. Those documents should be treated as text/plain.
> > 
> > At the moment, the spec backs that up.
> 
> Unfortunately, while you and I are on the same side, I can "pull an Ian" 
> here, and provide plenty of counter examples. [1] :-(

Oh, indeed. However, there is one thing that may mitigate that and make 
our life a lot easier here -- feeds generally are not visited directly, 
they're found in rel=feed and rel=alternate links on HTML pages. So this 
might be a non-issue basically.

(This works better for us for feeds than for HTML pages, which are also 
commonly sent as text/plain. In one study I did specifically for the 
sniffing section of the spec recently, looking at pages that started with 
"<HTML", I found one text/plain page for every 2000 text/html pages. I 
think we have to treat these as plain text for security reasons, but 
there's a strong argument saying we should treat them as HTML.)


> > So I would add a fifth condition: (5) the parameter is chosen such 
> > that browser vendors cannot ever get a competitive advantage by not 
> > supporting it or by supporting it incompletely.
> 
> Unfortunately, based on the quick list I gathered below, there is a 
> competitive advantage to be gained by ignoring the spec as it currently 
> stands.

I've been working with browser vendors to try and change the spec to be 
something that they can all agree on implementing. So hopefully, the spec 
will address all their concerns and in fact they wouldn't benefit 
significantly from ignoring it. But we do that by having them ignore 
Content-Type in certain cases; my point about proposals for a way to 
override this is that these proposals invariably ask that the header be 
honoured always, which is what will break down (just like it did with 
Content-Type). IMHO, anyway.


> Furthermore, the abstract way in which you have framed the problem means 
> that it applies to pretty much every feature and addition that is 
> present in HTML5 that isn't supported in IE6.

Yes, it's something we have to take into account for every feature. I 
think, however, that for every feature we've managed to get it to the 
point where supporting the feature is better than not supporting it (it's 
one reason we dropped, e.g., usemap="" on <input>). If there are cases you 
can see where not supporting a feature would be better than supporting it, 
please raise them.


> Finally, that competitive advantage thing can work both ways.  In a 
> field not too distant from the one that we are discussing, I've seen 
> cases where enough vendors have grown to support Atom specific features 
> simply because if the did not, they would be at a competitive 
> disadvantage.

Features, yes. Content-Type support isn't really a "feature". It's 
infrastructure, which, in my experience, means it's affected by different 
pressures.


> All theory aside, My read is that if we simply picked something like 
> ";important" to append to the content type and if IE8 supported it, and 
> if a few of us actually deployed content that behaved better if it were 
> honored, and publicized the fact that we did so, there would not be an 
> issue.

I encourage you to try to convince the browser vendors to give it a shot. 
It's a risky gamble, though. If they do try, but it turns out I'm right 
and the feature devolves after a decade or two, we'll have doubled the 
complexity of the sniffing algorithms in browsers (which bloats them) and 
the spec (which makes it harder to get interoperability at all). But if it 
works, it's probably worth it.

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

Received on Tuesday, 21 August 2007 23:35:43 UTC