XHR and fetch tests for redirect-to-cors behaviour don't match

[jdm]

#5070 introduced tests for making an XHR to a cross-origin URL that redirects when there is a POST body with a non-default Content-Type present. These tests (in xhr/send-redirect-to-cors.html) assert that the Content-Type remains unmodified after the redirection.

Following a long trail from whatwg/fetch#609 (which was fixed by whatwg/fetch#977) that introduced explicit behaviour to change POST to GET and remove any Content-Type value, I see #20596 which added tests in fetch/api/redirect/redirect-method.any.js that assert that the Content-Type is removed from the redirected request.

We are now in the strange situation where:

• all browsers pass send-redirect-to-cors.htm
• most browsers pass redirect-method.any.html
• the XHR specification delegates to the Fetch specification for the actual relevant behaviour

What do we do about this state of affairs? In Gecko's case the Fetch and XHR code paths are completely different which explains how both tests can pass; I don't know enough about other browsers to state if they're in the same boat.

cc @annevk

[annevk]

@rwlbuis @JuniorHsu @yutakahirano this might interest you. Safari is consistent in not stripping in either place. (This is a bug, but maybe once fixed it'll fix both at once.) Both Chrome and Firefox seem buggy in that they have different behaviors between fetch and XHR. I'll send a PR for the XHR test and file bugs.