`iframe`的`src`属性无法直接添加自定义http请求头。本教程将介绍一种客户端javascript方法，通过`fetch` api发送带有自定义头的请求，获取响应内容，并利用`url.createobjecturl`将其作为本地资源加载到`iframe`中，同时讨论相关注意事项和限制，特别是跨域和安全策略的影响。
理解iframe的局限性
iframe元素是HTML中用于在当前文档中嵌入另一个HTML文档的强大工具。其核心属性src用于指定要加载的外部资源的URL。然而，浏览器在处理iframe的src属性时，会发送标准的HTTP GET请求来获取内容。HTML规范和浏览器安全模型明确规定，开发者无法直接通过iframe的HTML属性或常规JavaScript方法（例如，修改src属性）为这些由浏览器自动发起的请求添加自定义HTTP请求头。这种限制主要是出于安全考虑，以防止恶意脚本操纵请求并可能绕过某些服务器端验证。
值得注意的是，像https://google.com这样的公共网站，通常会通过X-Frame-Options或内容安全策略（CSP）等HTTP响应头来明确阻止其内容被嵌入到其他网站的iframe中。这意味着即使您设法为请求添加了自定义头部，这些网站的内容也可能无法在iframe中正常显示，浏览器会基于这些安全策略阻止渲染。
解决方案：利用JavaScript Fetch API与Blob对象
当确实需要在iframe中加载内容并为其初始请求添加自定义HTTP请求头时，我们可以采用一种客户端JavaScript驱动的间接方法。这种方法的核心思想是：不直接让iframe加载外部URL，而是先通过JavaScript的fetch API以编程方式获取内容（在此过程中可以自由添加自定义头），然后将获取到的内容转换为一个本地可访问的URL，再将这个本地URL赋值给iframe的src属性。
步骤详解：
- 发起带有自定义头的fetch请求： 使用fetch(url, options)函数。在options对象中，通过headers属性定义一个包含所需HTTP头的JavaScript对象。例如，您可以设置Accept-Language、Authorization或任何其他自定义头。
- 处理响应： fetch函数返回一个Promise，该Promise解析为一个Response对象。由于iframe需要的是文件形式的内容，我们需要从Response对象中提取内容并将其转换为Blob对象。Blob（Binary Large Object）是JavaScript中用于表示不可变原始数据的文件状对象的接口。
- 创建对象URL： 使用URL.createObjectURL(blob)方法。这个方法会为Blob对象创建一个临时的、浏览器内部的URL。这个URL的格式通常是blob:http://yourdomain.com/some-uuid，它指向浏览器内存中存储的Blob数据。
- 设置iframe的src： 最后，将生成的对象URL赋值给目标iframe元素的src属性。此时，iframe会从浏览器内存中加载内容，而不是直接向外部服务器发起请求。
示例代码：
以下是一个具体的JavaScript示例，演示了如何实现上述过程：
带自定义头的iframe加载示例
在iframe中加载带自定义HTTP头的外部内容
下方iframe将通过JavaScript加载内容，并为其请求添加自定义HTTP头。
在上述代码中，fetch请求被发送到https://httpdump.io/ze5pz/dumpyard，并携带了Accept-Language、X-Custom-Header和User-Agent等自定义头。响应内容被转换为Blob，然后通过URL.createObjectURL生成一个本地URL，最终赋值给iframe的src。
注意事项与局限性
尽管上述方法能够实现为iframe加载内容时添加自定义请求头，但它并非没有限制。在实际应用中，您需要考虑以下几点：
- 跨域资源共享 (CORS)： fetch请求仍然严格遵守浏览器的同源策略和CORS机制。如果目标服务器没有设置适当的CORS响应头（例如Access-Control-Allow-Origin），浏览器将阻止fetch请求，导致无法获取内容。这意味着您无法使用此方法从不允许跨域请求的网站（如大多数公共网站）获取内容。
- X-Frame-Options和内容安全策略 (CSP)： 即使您成功通过fetch获取了内容并将其转换为blob: URL加载到iframe中，目标网站可能仍然通过X-Frame-Options或CSP指令阻止其内容在iframe中显示。这些安全机制是在内容被加载后由浏览器执行的，与请求头无关。此方法无法绕过这些服务器端或浏览器端的安全策略。
- 本地blob: URL的上下文： iframe最终加载的是一个blob: URL，这意味着其上下文与原始的外部URL完全不同。iframe内部的脚本将认为它们是在一个blob:域中运行，而不是原始的外部域。这可能会影响iframe内部脚本的行为，例如，如果它们依赖于原始域名进行API调用或访问localStorage。
- 资源释放： URL.createObjectURL创建的URL是临时的，并且在文档卸载时会自动释放。但在某些频繁创建此类URL的单页应用场景中，为了更精细地管理内存，您可能需要手动调用URL.revokeObjectURL(url)来显式释放不再需要的对象URL所占用的内存。
- Django应用场景： 尽管此解决方案是客户端JavaScript，但它与Django后端应用可以很好地协同工作。如果您的Django应用需要为用户提供一种方式来加载带有自定义头的外部资源，这种客户端方法是可行的。然而，如果您的Django应用本身是内容的提供者（即iframe要加载的内容是由您的Django服务器生成），那么更直接和推荐的方法是在Django视图中直接设置HTTP响应头，而不是在客户端进行这种复杂的处理。
总结
iframe的src属性本身不提供添加自定义HTTP请求头的功能。要实现这一需求，开发者必须采用客户端JavaScript的间接策略。通过结合fetch API来发送带有自定义头的请求，获取响应内容，并利用URL.createObjectURL将内容转换为本地可加载的blob: URL，然后将其赋值给iframe的src，可以有效地解决这一问题。然而，在实施此方案时，务必充分理解并考虑CORS、X-Frame-Options和CSP等浏览器安全策略的限制，它们是决定内容能否成功加载和显示的关键因素。
