Playwright中自定义响应头与CORS机制解析

在使用Playwright进行网络请求模拟时，开发者可能会遇到一个常见问题：为什么通过route.fulfill()方法设置的自定义响应头在客户端无法获取？本文将深入探讨这一现象背后的技术原理。

问题现象

当开发者使用Playwright的route.fulfill()方法拦截请求并返回自定义响应时，可能会尝试添加自定义头部信息：

await route.fulfill({
  json: { foo: 'bar' },
  headers: { 
    'x-custom-header': 'foo'
  }
});

然而在客户端通过fetch API获取响应时，却发现自定义头部x-custom-header并未出现在响应头中。

根本原因

这一现象并非Playwright的缺陷，而是浏览器安全机制——CORS(跨源资源共享)在起作用。CORS对响应头部的可见性有严格限制：

1. 简单响应头：如Content-Type、Content-Length等默认暴露
2. 自定义头：需要服务器明确通过Access-Control-Expose-Headers声明

解决方案

要使自定义头部对客户端可见，必须同时设置Access-Control-Expose-Headers：

await route.fulfill({
  json: { foo: 'bar' },
  headers: { 
    'x-custom-header': 'foo',
    'access-control-expose-headers': 'x-custom-header'
  }
});

技术细节解析

1. CORS头部处理机制：

   • 浏览器会先检查响应中是否包含Access-Control-Allow-Origin
   • 然后检查Access-Control-Expose-Headers是否包含自定义头
   • 只有明确声明的头部才会暴露给客户端JavaScript

2. Playwright的特殊性：

   • Playwright允许模拟跨域请求的响应体而不需要CORS头部
   • 但对于响应头部的处理完全遵循浏览器标准行为
   • 这种设计保证了测试环境与真实浏览器行为的一致性

最佳实践建议

1. 在测试环境中模拟API时，应完整复制生产环境的CORS头部配置
2. 对于需要测试自定义头部的场景，确保配置正确的Access-Control-Expose-Headers
3. 使用浏览器开发者工具验证实际响应头部是否包含所需信息

理解这些底层机制有助于开发者更有效地使用Playwright进行网络请求的测试和模拟，确保测试结果真实反映生产环境行为。