Closed Bug 362043 Opened 14 years ago Closed 14 years ago

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

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9alpha5

People

(Reporter: sayrer, Assigned: sciguyryan)

References

(Depends on 2 open bugs)

Details

Attachments

(1 file, 1 obsolete file)

since this can be something other than XML. In the XML case, it would still be nice to know without sniffing the XML itself.
Don't we just put whatever the server gave us in there?
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.
OS: Mac OS X 10.3 → All
Hardware: PC → All
Attached patch Possible patch v1 (obsolete) — Splinter Review
Possible patch v1
Assignee: general → sciguyryan
Status: NEW → ASSIGNED
Attachment #260524 - Flags: superreview?(peterv)
Attachment #260524 - Flags: review?(peterv)
I think in the XML case you just want the document to describe itself, actually. Why would you want to provide the encoding?
(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.
I should have defaulted |charset| too UTF-8 if there are problems so we don't end up with |;charset=| appended.
Attachment #260524 - Attachment is obsolete: true
Attachment #260588 - Flags: superreview?(peterv)
Attachment #260588 - Flags: review?(peterv)
Attachment #260524 - Flags: superreview?(peterv)
Attachment #260524 - Flags: review?(peterv)
Attachment #260588 - Flags: superreview?(peterv)
Attachment #260588 - Flags: superreview+
Attachment #260588 - Flags: review?(peterv)
Attachment #260588 - Flags: review+
Flags: in-testsuite?
Whiteboard: [checkin needed]
mozilla/content/base/src/nsXMLHttpRequest.cpp  1.179
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Target Milestone: --- → mozilla1.9alpha5
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).
(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()|
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.
(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.
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.
(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.
Depends on: 382947
Depends on: 383071
I filed the bug, but given that this is your regression, you should really not have made others spend time on it, imo...
No longer depends on: 383071
Depends on: 392046
Depends on: 396122
Depends on: 442030
Depends on: 441779
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.