Re: [XHR] Some comments on "charset" in the Content-Type header

On 10/9/09 7:26 AM, Anne van Kesteren wrote:
> Are you willing to modify Gecko to a model where if Content-Type has
> been set by setRequestHeader() the charset parameter is changed if
> present to the encoding used and is not set when not present. And where
> if Content-Type has not been set setRequestHeader() it is set by the
> user agent including charset parameter?

I think you're asking the wrong person; I didn't add the code initially. 
  I've just been one of the people stuck with dealing with the fallout.

For what it's worth, I believe the majority of compat issues are with 
multipart/form-data and the www-url-encoded type, and that in cases when 
XML is being sent (in the inputEncoding, at least), not having the 
charset is a PITA, at least for cross-site requests.

Perhaps we should only set the charset for cross-site requests, and 
assume that anyone who's sending data to themselves can deal however 
they please?

> Specifically, if the application does:
>
> setRequestHeader("content-type", "foo/bar")
>
> or some such you'll leave it alone.

I honestly don't care all that much, all things considered.

>> Doesn't that change the handling of URIs in the document, specifically
>> the situations where URI escapes are to be interpreted in the document
>> encoding?
>
> Actually, that would be the case for characters that are not escaped
> using percent-encoding.

Both, actually, depending on what you're doing with the URI.  If you 
need to show the URI to the user, you want to unescape things, and 
assume an encoding as you do so.

-Boris

P.S.  It's tempting to "unilaterally" remove this source of annoyance 
from our code and stop worrying about all the poor people trying to use 
cross-site XHR.  They can just talk to the server operator about encodings.

Received on Saturday, 10 October 2009 02:45:54 UTC