Affects: v5.3.6

It's connected to https://github.com/spring-projects/spring-framework/issues/24763 - CorsConfiguration based on pattern matching. While feature itself works really well, I found few corner cases where it's difficult to configure such patterns because of limitations that current pattern syntax provides.

  1. Sometimes origin contains a trailing slash. I think https://*.company.domain should match both https://test.company.domain and https://test.company.domain/. One workaround would be to add two different patterns, one with trailing slash and one without.
  2. Origins could contain port numbers. Currently it's impossible to support generic port with current syntax. As https://*.company.domain* could match https://test.company.domain:80 as well as https://test.company.domain.some.other.domain which is not what intended. Workaround here can be also creating two origins patterns: https://*.company.domain and https://*.company.domain:*.
  3. Would be nice to have possibility to support both http and https in a single pattern.

While there are workarounds as mentioned before, I think this should be supported out of the box (at least 1 & 2). What's more if you want to support 1 & 2 right now you would effectively either would need to create 4 different patterns or if you know how this is working inside spring you would end up with following pattern in your configuration: https://*.company.domain\\E\(:\\d+)?/?\\Q. Which is probably not the best approach either.

I see two possible solutions:

  1. When doing pattern matching against request origin remove trailing slash and port from it and do pattern matching just on host or schema+host
  2. Extend existing pattern syntax, so that it allows to configure patterns with generic port and optional trailing slash.

Comment From: rstoyanchev

We already ignore any trailing slash in CorsUtils.isCorsRequest where we match only scheme, host, and port. We should also be ignoring it for the actual check against allowed origins. This is something we can fix.

The port number cannot be ignored by default as it is part of what defines a cross-domain request. We can enhance the pattern syntax, maybe a comma separated list of ports or a wildcard:

https://*.example.com:[8080]
https://*.example.com:[8080,9000]
https://*.example.com:[*]

/cc @sdeleuze, @rwinch

Comment From: korektur

Yeah, that actually makes sense.

Comment From: sdeleuze

Specifying multiple patterns (so doing just dddcc5e9adaad0a85ae40664317e501c0cdf46aa as part of this issue) or improving the pattern syntax as well as you proposed @rstoyanchev sounds both ok to me, so up to you if we add this capability or not.

Comment From: rstoyanchev

I've created #26926 to separate that as enhancement. We're too close to the 5.3.7 release to add that and it would be useful to collect more feedback.