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

Re: Recent spec change to XMLHttpRequest default Content-Type

From: Carsten Orthbandt <carsten@pixeltamer.net>
Date: Fri, 15 Jun 2007 19:23:29 +0200
Message-ID: <4672CB11.8010909@pixeltamer.net>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: public-webapi@w3.org

Boris Zbarsky schrieb:
> 
> Carsten Orthbandt wrote:
>> The (IMHO) valid reason here is:
>> - redundant header overhead
>> - the UA isn't even meant to interpret the response, so it doesn't need
>>   any information on how to parse it
> 
> Actually, you're expecting the UA to convert the bytes in the response 
> into characters in this case.  Ideally, you would be sending a 
> Content-Type header with a charset parameter if you want that sort of 
> thing to be happening...
> 
> -Boris

Yes and no. I am expecting to eventually get a valid char representation
out of the response body. And the XHR draft spec says (last time I looked
that up) that the default char set is UTF-8. Which is totally fine with
me and therefor redundant.
Specifying a content type would be ideal but it bloats my headers. Since
everything I would specify is the (according to the last specs) default
anyway, we decided to strip that field.
It's obviously no big deal to re-add it. The point is that all available
material said that stripping Content-Type would be fine and in fact it
was. Now it's not and I suspect that we are not the only ones to get
bitten by it.
A webapp that spews hundreds of red errors in Firefox is simply not an
option.


Best regards,

Carsten Orthbandt


pixeltamer.net
c/o Carsten Orthbandt
Baumschulenstrasse 102
12437 Berlin
+49 (0) 30 34347690
Received on Friday, 15 June 2007 17:23:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT