Re: Why Microsoft's authoritative=true won't work and is a bad idea

On Mon, 7 Jul 2008, Julian Reschke wrote:
> Ian Hickson wrote:
> > > I wouldn't consider trusting the server supplied content type an 
> > > "extreme."
> > 
> > Compared to the status quo, it is an extreme. (If you consider the 
> > possible implementation space as a multidimensional phase space, and 
> > consider the current implementations are points in phase space, they 
> > are all relatively close to each other, and close to HTML5. The 
> > position that involves no sniffing at all, whether that be 
> > HTTP-compliance or this new authoritative=true parameter, is far, far 
> > from the browsers.)
> 
> It's an "extreme" that is currently allowed in HTML5, remember?
>
> "If the user agent is configured to strictly obey Content-Type headers 
> for this resource, then jump to the last step in this set of steps." -- 
> <http://www.w3.org/html/wg/html5/#content-type0>

Yes, you asked for it. It's not an extreme that anyone is going to 
implement in widely distributed software. (The HTML5 spec similarly allows 
UAs to abort with a fatal error when they come acros a parse error, but 
you won't see that implemented widely either.)


> It seems you are satisfied with the equilibrium HTML5 defines.

No, I hate the status quo. I wish Content-Type was followed to the letter. 
I just don't see that as a realistic possibility given how the Web works 
today.


> Many think that the information supplied by the server must be treated 
> as authoritative, thus want to reach a *different* equilibrium. That may 
> require more changes, but this doesn't mean it can't be done (despite 
> what you say).

Well, let me know when you succeed.

I worked hard (writing test suites, filing bugs, contacting engineers 
directly, etc) from about 1998 to about 2007 to get multiple vendors to 
change their ways and adopt a more strict implementation of Content-Type 
headers. In fact, I think it's probably not a stretch to say that I've 
done more than anyone else to push for strict Content-Type conformance.

Based on that experience, I don't believe that it is possible to reach 
that state and stay there. It simply isn't feasible given the economics of 
the Web. At least, that's what I've concluded.

Please, prove me wrong.


> > I would aboslutely love it if the relevant groups would take this 
> > stuff and specify it themselves. However, the HTTP group has already 
> > indicated
> 
> With "it", what exactly do you mean? The thing these groups will agree 
> on, or the thing you prefer personally?

Anything that can lead to interoperability, the browsers doing what the 
specs say, and the specs being a complete description of what browsers 
have to implement would be good as far as I'm concerned. What exactly the 
specs say isn't my main concern.

Right now, HTTP is incomplete (it doesn't define, e.g., error handling), 
and doesn't match reality (e.g. browsers don't obey Content-Type like HTTP 
says they should).

Whether the browsers change to match HTTP or HTTP changes to match the 
browsers or they both change and meet at a middle ground, I don't mind.

However, if the groups agree on something that is either incomplete (i.e. 
doesn't define precise behaviour for every case, including error cases) or 
is something vendors won't implement, then that's no good.

The same applies to the URI specs.

(Both HTTP and URI mailing lists have had people request these issues be 
addressed; in both cases the requests were dismissed. I don't really care 
enough to fight this; in the meantime, HTML5 will fill in the holes. 
Incidentally, I don't really care about drawing partisan lines around what 
applies to HTML and what applies to browsers and what applies to Other 
Specs and Other Software and so on. As far as I'm concerned there's only 
one Web and we need one coherent set of rules for everything on the Web, 
whether it's HTML or not, and whether it's browsers or not.)


> > > With the current text in HTML5, there's not only no "good answer" 
> > > but no answer at all (except by telling users to configure their UAs 
> > > to respect mime types).
> > 
> > This problem has nothing to do with the spec, since the spec currently 
> > requires text/plain to be honoured in this case.
> > 
> > The "bad" answer is for Sam to stuff the top of this text/plain feeds 
> > with filler content that doesn't get sniffed, so that the sniffing 
> > heuristics in IE and Firefox get tricked into not seeing the feed 
> > content. (So, there _is_ an answer, it's just not a good one.)
> 
> That may be a workaround that works in this case, but I doubt it's 
> universally applicable.

Yes... it's not a "good" answer...


> > > Sam's use case could be made compatible by making the response 
> > > distinguishable from one sent by a misconfigured server.
> > 
> > How is that possible?
> 
> Using Microsoft's proposal or by using a separate header, for instance.

And how do you distinguish someone using the parameter or header correctly 
from one using it in a misconfigured case?


> Well, the biggest vendor just put a proposal on the table that would 
> make it possible to disable sniffing altogether.

Only when a parameter is present, and only if nobody ever misues it. The 
parameter won't be always included, and it will almost certainly be 
misused. So it certainly won't be possible to disable sniffing altogether, 
and on the long term it almost certainly won't be possible to disable it 
altogether even when the parameter is included.


> Maybe it would make sense to consider it seriously, instead of 
> immediately stating "won't work"?

Please don't think that just because I can give a list of problems off the 
top of my head, I haven't seriously considered something. This idea was 
considered seriously _years_ ago. It's not a new idea.

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

Received on Monday, 7 July 2008 09:43:55 UTC