http - 服务器如何知道发送的请求带有凭据？

Question

我在通过我的网站从另一台服务器请求资源时遇到了一个问题。

我请求资源(通过范围请求请求的 PDF 文件)。浏览器(在本例中为 Chrome)向服务器发送一个 OPTIONS 请求。服务器从 OPTIONS 返回 200，但 header 之一是 - Access-Control-Allow-Credentials: true由于服务器公开了通配符 *对于 Access-Control-Allow-Origin响应 header ，Chrome 然后(我认为)从服务器抛出以下响应并给我一个错误，指出如果发出请求，服务器无法公开通配符 withCredentials = 'include' .

现在，我没有设置 withCredentials在我的代码中我可以看到的任何地方进行标记，我似乎无法找出服务器如何知道是否使用凭据发送了请求。我的 cookie 没有随 OPTIONS 或 GET/PARTIAL CONTENT 请求一起发送。我可以看到请求中没有其他特殊 header 。

所以，

1. 服务器如何知道以及我如何在客户端告诉设置为包含的枯萎凭据？

2. 如果我没有在我这边设置凭据，是什么导致 Chrome 认为我使用的模式是 withCredentials = 'include' ?

3. 服务器是否应该发回 Access-Control-Allow-Credentials: true OPTIONS 之后所有请求的 header ？

Answer 1

1. How does the server know and how can I tell on the client side wither credentials are set to include?

接收服务器对客户端 withCredentials 设置一无所知。服务器只是在请求中收到某种形式的凭据，或者没有。就 CORS 协议(protocol)而言，接收服务器不会根据请求是否包含凭据来更改其行为。接收服务器要么只发回 Access-Control-Allow-Credentials: true 响应 header ，要么不发回。

2. If I'm not setting credentials on my side, what could be causing Chrome to think that the mode I'm using is withCredentials = 'include'?

这个问题的答案是主观的——这取决于服务器管理员打算为谁做出响应。但最佳做法是，您可能只想将 Access-Control-Allow-Credentials: true 发送回您知道并明确允许的特定来源。这就是为什么 CORS 协议(protocol)有限制，如果请求有凭据并且响应有 Access-Control-Allow-Origin: * (通配符)，它不允许你的前端代码访问响应 header 值。

3. Should the server be sending back the Access-Control-Allow-Credentials: true header on ALL requests after the OPTIONS?

Chrome 只会认为，如果模式真的是 withCredentials = 'include'。因此，要么您的客户端代码的某些部分 实际上设置了 withCredentials = 'include' — 或者，withCredentials = 'include' isn 't 实际上已经设置好了，但你出于某种原因只是认为它是。