Where in the spec is the content-type header filtered out on 301/302/303 redirects?

[wisniewskit]

I'm failing to see where an XHR that's 301/302/303 redirected (as in the tests in /xhr/send-redirect-post-upload.htm) would lose its content-type header to pass those tests, given the XHR and Fetch specs as-written.

That is, during step 4 of the XHR send() method, an author request header for the content-type will be added, but I don't see where it should be filtered out for the redirected request to meet this test's expectations.

I see HTTP-redirect fetch step 11, where the POST will become a GET if needed and the upload body will be nulled out, but where is the content-type filtered out, so that it isn't added right back to the request headers?

In addition, the "301 POST with string and explicit Content-Type safelisted" test in /xhr/send-redirect-to-cors.htm expects its explicitly-set content-type to not be filtered out, but does expect the body and content-length to be stripped away.

And so I'm lead to believe that the content-type header shouldn't be removed when explicitly set by the user (unless blocked by CORS), but it should be removed when it's implicitly computed in send() step 4?

[annevk]

This is a duplicate of whatwg/fetch#609, right?

[wisniewskit]

Hmm. They do sound the same (or at least this seems to be a Fetch issue rather then XHR issue), but maybe there's still a detail that hasn't yet been considered.

In both of the tests I mention above, they end up being 301 redirects that drop from a POST to a GET, so both of them should lose their bodies and content-types... but the CORS-related one expects the safelisted content-type header to not be stripped away. And Chrome and Firefox are passing both tests, so I'm not sure why there isn't a conflict between these tests. That's why I think that it matters if the header was explicitly declared, which I don't see being considered in that Fetch issue.

[annevk]

I suspect that is the inconsistency @ricea refers to in the other issue. We should probably consistently strip.

[wisniewskit]

Alright, then I'll close this as a dupe and ask in that issue about the inconsistency.