Remove Content-Type special case in XMLHttpRequest

NEW
Unassigned

Status

()

Core
DOM
4 years ago
4 years ago

People

(Reporter: annevk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
This is a follow up to bug 700589 to investigate removing https://hg.mozilla.org/mozilla-central/rev/4b085d906272#l1.12

We should really move to a place where we have the same Content-Type parsing everywhere.
What do other UAs do here?
(Reporter)

Comment 2

4 years ago
I don't think they manipulate charset at all. Have not tested this recently.

Comment 3

4 years ago
Back when I looked at this ~2 years ago, Firefox was the only UA that *attempted* to implement this XHR requirement.
The requirement is there because of the compat constraint that the code in question was trying to address, as I recall.

So how do other UAs handle that compat constraint?
(Reporter)

Comment 5

4 years ago
No, it's because someone involved with Gecko wanted to always tell the server about the encoding of the resource being transmitted. Nobody else seemed to really care...
Hmm.  So other UAs are happy to just let the server flounder?  :(

Comment 7

4 years ago
(In reply to Boris Zbarsky [:bz] from comment #6)
> Hmm.  So other UAs are happy to just let the server flounder?  :(

As far as I recall, this is about an edge case of an edge case. XHR caller sets incorrect Content-Type (+ charset), XHR overwrites the Content-Type but tries to preserve the upper/lowercasing of the charset param *if* it was correct otherwise.
You need to log in before you can comment on or make changes to this bug.