Spring中CORS自动添加Vary:Origin头的原因及禁用方法咨询

一、为什么Spring在允许源为*时还会加Vary:Origin？ #

Spring的CORS处理是通用化的设计逻辑，它并没有针对*这种通配符源做特殊判断。不管你配置的是单一具体源还是通配符，默认的CORS处理器都会统一添加Vary:Origin头——框架默认假设响应内容可能会因请求的Origin不同而变化，并没有额外做“如果是*就跳过加这个头”的分支处理。

二、除了自定义过滤器，还有其他禁用方式吗？ #

目前Spring官方没有提供直接关闭这个行为的配置开关，但可以通过两种相对优雅的方式处理：

• 自定义CorsConfiguration子类：重写获取Vary头的方法，移除Origin项。示例代码：

  public class NoOriginVaryCorsConfig extends CorsConfiguration {
      @Override
      public List<String> getVaryHeaders() {
          List<String> originalVary = super.getVaryHeaders();
          originalVary.remove("Origin");
          return originalVary;
      }
  }
  

  之后在你的CORS配置类里，用这个自定义类来构建CorsConfigurationSource即可。
• 单个接口手动控制响应头：如果只是个别接口需要，返回ResponseEntity时手动移除Vary头：

  @GetMapping("/public-data")
  public ResponseEntity<String> getPublicData() {
      HttpHeaders headers = new HttpHeaders();
      headers.remove("Vary");
      // 也可以直接设置Vary为你需要的头，比如只保留Cache-Control相关
      return new ResponseEntity<>("fixed content", headers, HttpStatus.OK);
  }
  

  不过这种方式只适合单个接口，全局场景不推荐。

三、自定义过滤器VS @CrossOrigin+移除头，哪个更简便？ #

分场景来看：

• 全局场景：直接用自定义过滤器设置CORS头更简便。因为用@CrossOrigin后还要额外加全局拦截逻辑去移除头，多了一层冗余步骤；而自定义过滤器可以一次性完成CORS头配置和Vary:Origin的移除，逻辑集中，维护起来更省心。
• 单个接口场景：用@CrossOrigin配合手动移除响应头更轻量，不需要搞全局配置。

内容的提问来源于stack exchange，提问作者Paul Wellner Bou