获取API，自定义请求标头，CORS和跨源重定向 [英] Fetch API, custom request headers, CORS, and cross-origin redirects

问题描述

我需要在浏览器中使用自定义请求标头发出HTTP GET请求，并在流入时处理结果.Fetch API非常适用于此：

I need to make an HTTP GET request with custom request headers in-browser and process the result as it streams in. The Fetch API is ideal for this:

fetch('https://example.com/resource', {
  method: 'GET',
  headers: {
    'X-Brad-Test': 'true'
  },
  cache: 'no-store',
  mode: 'cors'
}).then((res) => {
  const reader = res.body.getReader();
  // etc.
});

这很有效。由于存在自定义标头，因此浏览器会使用OPTIONS请求将请求预先安排到 / resource 。我已将服务器配置为使用 204无内容以及以下标题进行响应：

This works quite well. Since there are custom headers, the browser pre-flights the request with an OPTIONS request to /resource. I have configured my server to respond with a 204 No Content and the following headers:

Access-Control-Allow-Headers: X-Requested-With, Range, If-Range, X-Brad-Test
Access-Control-Allow-Origin: *

浏览器对此感到满意，然后发出GET请求，服务器返回 200 OK 包含数据，浏览器允许我访问响应标题和正文。

The browser is happy with this, then makes a GET request, the server returns a 200 OK with the data, and the browser allows me to access the response headers and body.

当存在重定向时，问题就出现了。 OPTIONS 请求成功使用 204 No Content 以及与之前相同的标头。浏览器发出正确的 GET 请求，并在服务器上发送 302 并带有位置：标题。 Chrome会引发以下错误：

The problem comes in when there is a redirect. The OPTIONS request succeeds with the 204 No Content and the same headers as before. The browser makes the correct GET request, and on the server I send a 302 with a Location: header. Chrome throws the following error:

获取API无法加载 https://example.com/resource 。从' https://example.com/resource '重定向到' http：// some-other-origin / resource 已被CORS政策阻止：请求需要预检，不允许跟踪来源重定向。

Fetch API cannot load https://example.com/resource. Redirect from 'https://example.com/resource' to 'http://some-other-origin/resource' has been blocked by CORS policy: Request requires preflight, which is disallowed to follow cross-origin redirect.

这是出乎意料的，对我来说似乎毫无意义。我希望浏览器遵循重定向，并为这个新位置做另一个飞行前请求，但它没有这样做。

This was unexpected, and seems nonsensical to me. I expected the browser to follow the redirect, and do another pre-flight request for this new location, but it didn't do that.

陌生人仍然是我可以这个客户端的黑客攻击。我可以在没有自定义标头的情况下发出HTTP请求，通过查看Response对象找出重定向后的结果，然后使用我的自定义标头在新目标上发出第二个请求。当然，这在所有情况下都不起作用，我宁愿不依赖这个黑客。我宁愿找到合适的方式。

Stranger still is that I can sort of hack around this client-side. I can make an HTTP request without my custom header, figure out where I ended up after redirects by looking at the Response object, then make a second request at the new target with my custom headers. This doesn't work in all cases of course, and I'd rather not rely on this hack. I'd rather find a proper way.

两个问题：

• 什么是允许客户端遵循重定向的正确方法吗？我可以使用某种 Access-Control - * 标题吗？


• 为什么存在这种限制？不跟踪并在后续网址上运行预转移会阻止哪些安全问题？

• What is the proper way to allow the client to follow redirects? Is there some sort of Access-Control-* header I can use?
• Why does this restriction exist? What security issue is prevented by not following and running pre-flight on the followed URL?

推荐答案

支持重定向到需要预检的请求是最近对Fetch（定义CORS）的更改。

Supporting redirects to requests that require a preflight is very recent change to Fetch (which defines CORS).

https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2

我相信一些实现已经开始调整他们的实现，但这需要一些时间才能达到每个人。

I believe some implementations have started adjusting their implementations, but this will take some time to reach everyone.

这篇关于获取API，自定义请求标头，CORS和跨源重定向的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！