You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: