我正在尝试存储CSRF保护（查询字符串+ cookie）API POST请求，以便在webapp重新联机时重播。
为此，我想在IndexedDB中保存请求对象（Fetch API），但IDBObjectStore.put失败并出现DataCloneError“无法克隆对象”。
Request对象有一个简单的JSON主体，没有二进制数据，只有所有字符串 这是在服务工作者（Web worker）环境中运行的。
结构化克隆算法有没有理由不克隆请求对象？ [Answer: Yes] 如果是这样，除了结构化克隆之外，对于该对象进行脱水/再水化的最佳选择是什么？
我真的想避免知道/访问Request对象的各个属性。 我需要的部分是网址，标题，正文和cookie（但同样，我不希望代码必须知道这些）。
提前感谢任何建议。
答案 0 :(得分：4)
您确定需要在indexedDB中存储auth cookie和CSRF参数，而不是在重播Request时重新生成它们吗？
我们在Google I/O 2015 Web App和ended up中遇到类似的情况，只是在IndexedDB中存储基本请求信息（URL +方法，但序列化的JSON主体在概念上是相同的）。每次加载页面并且有可用的有效凭据时，我们检查了IndexedDB以查看是否有任何排队的重播请求，如果是，则将它们发送到具有新凭据的服务器。
我们没有多少选择，因为我们使用的凭据在一小时后过期，但总的来说，只要有机会获得您的凭据，这似乎是一个合理的模式＆＃39 ;重新使用可能会过时。
（如果用户退出，您显然希望清除IndexedDB中的排队请求，但无论如何都是必要的。）