I used to use version 2.1.3 before. Today, after upgrading to 2.3.3, the browser CORS reported that it had responded to origin for many times. Then I tested the version after 2.2.0 and found this problem. Here is my code. I don't know what the problem is
Comment From: wilkinsona
Thanks for the report. Unfortunately, there isn't enough information here to diagnose the problem. For example, Spring Security may add CORS headers and I can't tell if you're using it. If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.
Comment From: shenzhenMirren
@wilkinsona Hello! I found that this problem is caused by calling addHeader. If setHandler is called, it will not.
Maybe this problem should be handled by springboot, because the browser does not accept two origins
This is the demo urlCORS-Origin-Responded-Twice
Comment From: bclozel
I had a look at your sample. With Spring Boot 2.3.x, sending a request using httpie does show duplicate response headers:
$ http http://localhost:8686/project Origin:https://foo.example
HTTP/1.1 200
Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Type: application/json
Date: Wed, 26 Aug 2020 08:05:48 GMT
Keep-Alive: timeout=60
Transfer-Encoding: chunked
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
{
"test": "test"
}
I can reproduce the same behavior using Spring Boot 2.1.x so I'm confused - do you have a sample project that doesn't show this behavior with a particular Spring Boot version? Which version?
Your controller asks for CORS support with the @CrossOrigin annotation. Spring Framework will add the relevant response headers using HttpServletResponse.setHeader, but it does so before calling the actual handler method. In your sample, the handler method adds another Access-Control-Allow-Origin header to the response.
I don't think there's any issue in Spring Framework or Spring Boot, as the application should not write those headers. As for why headers are added or set, it's the very nature of the Servlet API as you've found out.
Comment From: shenzhenMirren
@bclozel Sorry, my original problem occurred in HandlerInterceptor. After finding the problem, I didn't add HandlerInterceptor again for test. I re submitted the code to demo
What I want to express is that although it is not standardized for users to call AddHeader, but the browser can not accept two Access-Control-Allow-Origin, maybe @CrossOrigin should judge whether there is Access-Control-Allow-Origin in the header.
Comment From: bclozel
As I've said before, the CORS support in Spring Framework is using the setHeader method, effectively replacing any existing value - and this is being done before the controller handler method is called.
So there is no way for Spring Framework to prevent the application from calling response.addHeader after the fact - in a controller, a Servlet filter, or any other place happening after those headers have been set by Spring CORS support.
I'm closing this issue as invalid since the application code is not supposed to add CORS-related headers if Spring CORS support is being used.