Bounded wildcard support?

This library uses HttpOriginRange from akka-http to perform its matching.

Unfortunately, there is no way to extend HttpOriginRange or HttpOrigin in order to support more sophisticated/alternate matching.

This means that whilst it’s possible to match all hosts (HttpOriginRange.*) or a set of fixed hosts (HttpOriginRange.Default(...)), it’s not possible for CORS purposes to match for example *.somedomain.com.

I would open this as an issue upstream, but it’s unclear to me whether this is a request that’s applicable to other uses of their HttpOriginRange or is specific to akka-http-cors’s use of it.

So in summary:

• Would it be possible here to add support for matching on bounded wildcards.
• Should this issue go upstream to akka-http instead?

[lomigmegard]

I will have a look again at this then, I think I remember I had an issue implementing it.

[lomigmegard]

Hey, I knew one day someone would raise this issue 😉

Modifying HttpOriginRange or HttpOrigin is impracticable for two reasons:

• A HttpOrigin is strictly defined in RFC-6454 and it doesn’t allow some matching segments. A HttpOrigin is used in many places and we can’t modify his semantic for CORS.
• The range is used directly in the Access-Control-Allow-Origin header and the W3C defines its content strictly.

I looked at other CORS implementations to see how they deal with this:

• The CORS filter from Dzhuvinov Software adds a new setting allowSubdomains.

  If true the CORS filter will allow requests from any origin which is a subdomain origin of the allowed origins. A subdomain is matched by comparing its scheme and suffix (host name / IP address and optional port number).

• The CORS filter from eBay doesn’t allow it.
• […] please add more

Adding a new setting allowSubdomains is possible, but this mechanism is not defined by the W3C. This setting would only change the matching logic, not the content of the Access-Control-Allow-Origin header.

Thoughts?