W3C home > Mailing lists > Public > public-webapi@w3.org > June 2007

Re: Recent spec change to XMLHttpRequest default Content-Type

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 15 Jun 2007 11:06:39 +0200
Message-ID: <4672569F.1000506@gmx.de>
To: Carsten Orthbandt <carsten@pixeltamer.net>
CC: "Web API WG (public)" <public-webapi@w3.org>

Carsten Orthbandt wrote:
> 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.

There is no standard, not even a "recommendation" for XHR. This group is 
working on a first version of a recommendation, so there's nothing it 
can break spec-wise. It may not be fully compatible with what current 
implementations do, but that's a separate discussion.

> 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.

Again, there is no "specced" behavior as of today.

> 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.

I totally disagree. Your application is violating a SHOULD level 
requirement in RFC2616, which points out that this may cause recipients 
to guess the content type. And it's exactly for that reason that you see 
the errors logged.

So again, it it hurts, don't do it. Just assign a content type.

> 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.

I think you're confused about the status of the XHR spec. It's work in 
progress. There is no prior spec getting revised.

Best regards, Julian
Received on Friday, 15 June 2007 09:07:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC