Use requested URI info in CORS decision-making #7585
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(also remove temporary workaround for now-fixed MP OpenAPI TCK bug)
Resolves #5786 and #3619
Description
Originally, the CORS decision-making used the
Host
header value from the incoming request. But intervening nodes--load balancers, etc.--might have overwritten that value making it useless for CORS.We added requested URI support some time ago to work with the
Forwarded
(and the related non-standardX-Forwarded...
headers); this PR enhances the CORS logic to make use of it.The original CORS code includes adapters around the SE and MP request types. Basically, those adapters are enhanced to expose the underlying request's URI info so CORS has access to it, and the CORS logic uses the host from that instead of directly from the
Host
header in making its decisions.Documentation
Revised doc files are part of this PR.