flutter开发web应用网络请求后台失败--记录遇到的跨源资源共享问题

前因

愉快开发flutter的web应用，发现网络请求后台一直请求不通啊，百思不得其解后偶然遇到了跨源资源共享（CORS）这一名词，才发现了问题关键所在。

什么是跨源资源共享

引用跨源资源共享（CORS） - HTTP | MDN (mozilla.org)的专业分析，只列出关键点：

运行在 https://domain-a.com 的 JavaScript 代码使用 XMLHttpRequest 来发起一个到 https://domain-b.com/data.json 的请求--->

出于安全性，浏览器限制脚本内发起的跨源 HTTP 请求

例如，XMLHttpRequest 和 Fetch API 遵循同源策略。这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源，除非响应报文包含了正确 CORS 响应头

----------------通俗一点讲即为

游览器本来是localhost的一个web，因为跨源资源共享限制，被禁止向后台（也就是某某ip的那个域）进行网络请求了

解决方式

还是引用mdn的图

发送端在请求报文增加如下字段表明自己的域

Origin: https://foo.example

后台返回的http响应报文增加如下字段表明自己的资源可以被任意外源访问

Access-Control-Allow-Origin: *

实际上，flutter开发web不需要也不能手动设置Origin字段，后台正确设置响应头字段即可

事实上，后台的相关字段不仅可以设置为*，也可以设置单个与多个域名

额外补充

为什么要有这个机制？

1. 保护用户数据：同源策略确保了一个源（例如一个网站）的脚本不能访问另一个源的文档属性或者其他资源。这种隔离帮助保护用户数据免受恶意网站的访问。

2. 防止跨站点攻击：例如，跨站点脚本攻击（XSS）和跨站点请求伪造（CSRF）。通过限制脚本只能与同一源的资源进行交互，减少了这类攻击的风险。

3. 数据隔离：同源策略确保了不同网站的数据不会相互干扰，从而提供了一种数据隔离机制。

为什么JSP不需要这么折腾？（鞭尸旧技术）

因为Tomcat等服务器，和“页面”是“本地”一起运行的