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
