-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(cors): avoid overwriting Access-Control-Expose-Headers
response header
#11136
fix(cors): avoid overwriting Access-Control-Expose-Headers
response header
#11136
Conversation
can this whole problem be avoided if configuring the value as |
you will also have to support this fix with test cases. |
Cannot set Our requirement is for the upstream service to customize the However, setting |
I submitted a test case to verify whether the removal of |
@ShiningRush was it intentional (by design) to allow setting |
Yes, |
Thank you! I have noticed that since the default values were removed, many of the previous test cases have failed. Do I need to modify these test cases? |
okay, makes sense now. Sorry for the hassle, I am not much familiar with cors 😂 . But your PR does two things:
so now the default behaviour is that if this field is not configured, Please consider this and update the PR title and add more details in the comment/docs about the changing behaviour. |
@shreemaan-abhishek 👌Thank you for your correction. I have updated the PR description and title. The documentation related to CORS has been revised. |
Access-Control-Expose-Headers
response header
1. Problem Description
I used version
APISIX 3.5
before and found that the code for theexpose_headers
setting in the core plugin is incorrect, which has not been addressed in thelatest branch
. This PR is intended to rectify this issue.The original relevant code is as follows:
This code describes the
expose_headers
configuration, suggesting that setting it to**
would expose all headers, but this is incorrect. The HTTP protocol does not have such a specification. You can refer to the description on MDN:https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers
So
**
is the wrong description and configuration, and setting it to*
is also conditional.2. Impact
If I enable this plugin globally and set
allow_methods
,allow_origins
, and other configurations, not settingexpose_headers
using the default value*
or setting**
will cause problems because the plugin's request header will override theAccess-Control-Expose-Headers
set by the upstream service, causing the upstream service to be unable to expose request headers.I can only hard-code the:
expose_headers: Content-Encoding, My-Revision, My-Ikun
This is unreasonable. If my upstream service needs to expose a new header
Project-App
, I have to configure it, and let the plugin configure it as:expose_headers: Content-Encoding, My-Revision, My-Ikun, Project-App
3. Recommended Solution
In most cases,
expose_headers
does not need to be set globally and can be managed by the upstream service.I have used
Kong
before, and the strategy of theKong
core plugin is to removeAccess-Control-Expose-Headers
from the response header if the user does not configure it.I suggest adopting a similar approach where the core plugin does not add
Access-Control-Expose-Headers
to the response header if the user does not configure it. This allows the upstream service to control the exposure of headers independently.So I made changes to the code:
The plugin will modify the
Access-Control-Expose-Headers
header and override the upstream service's configuration only when a value is explicitly set by the user.If no value is set, the plugin will not modify the header, allowing the upstream service to expose its own headers as needed.
Checklist