362043 - XMLHttpRequest should set a charset in the Content-Type request header

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Robert Sayre]

since this can be something other than XML. In the XML case, it would still be nice to know without sniffing the XML itself.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Don't we just put whatever the server gave us in there?

Comment 2

[Boris Zbarsky [:bzbarsky]]

This bug is about the _request_ header we send when doing a POST via XMLHttpRequest.  That is, we're sending the server some data, but we're not telling it how we encoded it.

Comment 3

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Possible patch v1

Possible patch v1

Comment 4

[Anne (:annevk)]

I think in the XML case you just want the document to describe itself, actually. Why would you want to provide the encoding?

Comment 5

[Robert Sayre]

(In reply to comment #4)
> I think in the XML case you just want the document to describe itself,
> actually. Why would you want to provide the encoding?
> 

Requests have different requirements than responses. Request metadata turns out to be much more useful to the recipient, because it is practical for servers to enforce application-specific coherence requirements.

Comment 6

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Possible patch v1.1

I should have defaulted |charset| too UTF-8 if there are problems so we don't end up with |;charset=| appended.

Comment 7

[Nickolay_Ponomarev]

mozilla/content/base/src/nsXMLHttpRequest.cpp  1.179

Comment 8

[Wladimir Palant]

I got a complaint in a forum that this breaks multipart/form-data requests. Is there any way to prevent charset from being added? This could be also an issue when the sender sets the charset header himself because he knows the encoding of the stream (unlike XMLHttpRequest which always assumes UTF-8).

Comment 9

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #8)
> I got a complaint in a forum that this breaks multipart/form-data requests. Is
> there any way to prevent charset from being added? This could be also an issue
> when the sender sets the charset header himself because he knows the encoding
> of the stream (unlike XMLHttpRequest which always assumes UTF-8).
> 

Actually it shouldn't always assume UTF-8 but it will if for some reason the charset of the document isn't returned by |baseDoc->GetDocumentCharacterSet()|

Comment 10

[Wladimir Palant]

I think most times you send a multipart/form-data request the data will be read from a stream and not from a document. Streams don't have any charset data associated with them.

Comment 11

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #10)
> I think most times you send a multipart/form-data request the data will be read
> from a stream and not from a document. Streams don't have any charset data
> associated with them.
> 

That's a good point. I guess we could only append the charset if we have a document and not a stream but I'm not sure if that would be much better than simply not setting it at all.

Comment 12

[Boris Zbarsky [:bzbarsky]]

If you set a charset, the recipient MUST (in the RFC sense) honor it.  If not, it can try to guess it from the data.  So if you don't know the charset, don't set it.

Is there a bug on this followup issue?  It should block 1.9, imo.

Comment 13

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #12)
> If you set a charset, the recipient MUST (in the RFC sense) honor it.  If not,
> it can try to guess it from the data.  So if you don't know the charset, don't
> set it.
> 
> Is there a bug on this followup issue?  It should block 1.9, imo.
> 

That's a simple fix, just don't set the UTF-8 default and check is the charSet is null before we add the charset information.

If someone fills a new bug please either cc me too it or mark me as the assignee and I'll get a patch up for that. Thanks.

Comment 14

[Boris Zbarsky [:bzbarsky]]

I filed the bug, but given that this is your regression, you should really not have made others spend time on it, imo...