Re: Recent spec change to XMLHttpRequest default Content-Type

I don't want to let loose a big discussion about best practices
here. The issue at hand is certainly solvable on our side.
But I do see a problem here with changing the spec in a way that
obviously breaks old apps that were fully standards compliant.
Sending a content type header was NOT required, now it is. But
the protocol (HTTP) didn't change at all.
I'd just like to see the XMLHttpRequest spec be changed in a
way that doesn't break existing applications. Not just because
of this content type problem but because I see a problem in the
general process here.
The change isn't needed at all. If it ain't broke, don't fix it.
Clarifying unclear sections of the spec is very good. But inverting
specced behaviour in doing so is not.
The problem with GranParadiso is certainly fixable there, but the
reason for the bug report is a deliberate spec change (or at least
I'm told so).

So to sum up:
My app was fully compliant with HTTP and XMLHttpRequest specs before
the change.
After the change it is not.
Ergo: The spec change breaks app compatibility. Which is bad.
And IMHO completely unnecessary.

If this is just the way the process is meant to work, ok. We can
certainly adapt to it. But I doubt that breaking appcompat is really
intended.


Carsten Orthbandt


pixeltamer.net
c/o Carsten Orthbandt
Baumschulenstrasse 102
12437 Berlin
+49 (0) 30 34347690

Received on Friday, 15 June 2007 08:56:34 UTC