httpd 重复 Access-Control-Allow-Origin 并带有“始终设置标头" [英] httpd duplicate Access-Control-Allow-Origin with "Header always set"

问题描述

我正在尝试在我的服务器上启用 CORS.它同时托管 Apache HTTPD 和 Apache Tomee.HTTPD 配置为:

I am trying to enable CORS on my server. It hosts both an Apache HTTPD and an Apache Tomee. HTTPD is configured as:

SetEnvIf Origin "^https://(.+\.)?my-domain.com$" allowed_origin=$0
Header always set Access-Control-Allow-Origin %{allowed_origin}e env=allowed_origin
Header set Access-Control-Allow-Credentials "true"
Header set Access-Control-Allow-Methods "GET, POST, OPTIONS, HEAD, PUT, DELETE, PATCH"
Header set Access-Control-Allow-Headers "accept,x-requested-method,origin,x-requested-with,x-request,cache-control,content-type"
Header set Access-Control-Max-Age "600"

和我的 Tomee Web XML :

and my Tomee web XML :

<filter>
  <filter-name>CorsFilter</filter-name>
  <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
  <init-param>
    <param-name>cors.allowed.headers</param-name>
    <param-value>Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Accept-Language,Keep-Alive</param-value>
  </init-param>
  <init-param>
    <param-name>cors.allowed.methods</param-name>
    <param-value>GET,POST,HEAD,OPTIONS,PUT,PATCH,DELETE</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>CorsFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

我的问题是我在对预检选项请求的响应中两次获得 Access-Control-Allow-Credentials 标头:

My problem is I get the Access-Control-Allow-Credentials header twice in the response to the preflight OPTIONS request :

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://my-origin.my-domain.com
Access-Control-Allow-Origin: https://my-origin.my-domain.com
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600
Access-Control-Allow-Methods: GET, POST, OPTIONS, HEAD, PUT, DELETE, PATCH
Access-Control-Allow-Headers: accept,x-requested-method,origin,x-requested-with,x-request,cache-control,content-type,authorization

我不明白为什么在我的 HTTPD 配置中使用 set 关键字不会删除重复的 Access-Control-Allow-Origin.此外，如果我删除always"关键字，它只会返回一个 Access-Control-Allow-Origin...

I don't understand why the usage of the set keyword in my HTTPD configuration does not remove the duplicate Access-Control-Allow-Origin. Moreover, if I remove the 'always' keyword it returns one Access-Control-Allow-Origin only...

推荐答案

遇到类似问题.花了很多时间调试.

Experiencing a similar issue. Spent a lot of time in debugging.

这是 Apache 中的一个错误.内部设计的失败以及未能对其进行记录.

It is a bug in Apache. A failure of the internal design and a failure to document it.

Header [table] set [cookie] [value] [...]

这是操作标题的命令.apache中至少有两个cookie表.

That's the command to manipulate headers. There are at least two cookie tables in apache.

• onsuccess，默认，用于 20X 状态代码.
• always，用于错误，包括重定向代码.

• onsuccess, default, used for 20X status codes.
• always, used for errors, including redirects codes.

根据我的实际经验判断，所有表中的所有 cookie 都附加到响应中.

Judging by my experience in the wild, all cookies from all tables are appended to the response.

在您的示例中，Tomcat 设置的 cookie 在 onsuccess 表中，apache 中的 cookie 设置在 always 表中.响应得到两个 cookie，因此是重复的.

In your example, the cookie set by Tomcat is in the onsuccess table, the cookie sets in apache is in the always table. The response gets both cookies, hence the duplication.

它变得比这更混乱.根据使用的模块不同，这些表具有不同的含义.例如，当使用代理或 CGI 时，如果上游服务器传送错误successfully，则 cookie 的相关表是 onsuccess，但是 always 如果发生内部apache错误.

It gets more messy than that. The tables have different meaning depending on what modules are in use. For instance, when using proxy or CGI, the relevant table for cookies is onsuccess if the upstream server delivers an error successfully, but always if an internal apache error occurs.

这种行为没有记录.这似乎不是故意的，而是 apache 内部的结果.在目前的状态下，Apache 基本上无法正确操作 headers.

This behavior is not documented. That seems not intentional but a consequence of apache internals. In the current state, it is basically impossible to manipulate headers properly with Apache.

这篇关于httpd 重复 Access-Control-Allow-Origin 并带有“始终设置标头"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！