Support appending header ranges to CorsSettings.

[timw]

Provide a CorsSettings builder method to allow additional header ranges to be added, and the underlying ability to concatenate HttpHeaderRange instances to support it.

This supports scenarios where complex CorsSettings defaults are provided by downstream libraries (e.g. pekko-grpc) but still need to be extended/adapted by end user applications.

A concrete motivating example is the pekko-grpc defaultCorsSettings, which include:

  val defaultCorsSettings: CorsSettings = CorsSettings(ConfigFactory.load())
    .withAllowCredentials(true)
    .withAllowedMethods(immutable.Seq(HttpMethods.POST, HttpMethods.OPTIONS))
    .withExposedHeaders(immutable.Seq(headers.`Status`.name, headers.`Status-Message`.name, `Content-Encoding`.name))
    .withAllowedHeaders(
      HttpHeaderRange(
        "x-user-agent",
        "x-grpc-web",
        `Content-Type`.name,
        Accept.name,
        "grpc-timeout",
        `Accept-Encoding`.name))

In one of our (development) environments, we need the Authorization header to be added to the allowed headers range, but the withAllowedHeaders method only works by override, requiring us to either maintain our own distinct set of headers (which could diverge from the upstream) or do hacky matches on the unsealed HttpHeaderRange type.

This is a proposal for discussion on a more ergonomic/robust way to extend default settings like this.
The same pattern could equally be applied to the HTTP origin matchers and possibly the exposed headers.

I've tried to make the implementation in-line with conventions (e.g. I would prefer to seal scaladsl.model.HttpHeaderRange and have all the matches over it be required exhaustive, but the rest of pekko-http isn't really that way inclined), and the concat implementation is also awkward as exposing it to the Java DSL means you have to deal with those type params in the Scala methods and discourage extension.

Happy to discuss and rework if maintainers have opinions/better ideas about approach here.

[pjfanning]

This should target main branch, not 1.4.

When it gets merged, we can consider backporting to 1.4.

The code doesn't compile in Scala 2.12 and causes binary compatibility issues for other Scala versions. This will be less of an issue in main branch (no Scala 2.12 support, for example).

[timw]

This should target main branch, not 1.4.

When it gets merged, we can consider backporting to 1.4.

Will rebase and re-push once you've had a chance for an initial comment.

The code doesn't compile in Scala 2.12 and causes binary compatibility issues for other Scala versions. This will be less of an issue in main branch (no Scala 2.12 support, for example).

Looks like that was due to the import changes (I haven't got much 2.12 experience TBH, so that's a bit mysterious) - will tidy all that up and check.

Will also have a think about binary compatibility - that might be harder to avoid if the concat API is to be available to the Java DSL, but it could be shunted to a utility method. The javadsl/scaladsl split does make things a bit suboptimal WRT sealing the types, so happy to take suggestions on the typical idioms there.

[pjfanning]

You can add an excludes file for the mima failures in main branch.

[timw]

Rebased this on main and changed the target branch for this PR - also fixed the compilation and import issues (have run validatePullRequest and full +compile locally).

[timw]

I've removed new method on CorsSettings as it's not strictly needed.
Clients of the API can add extension methods if they prefer to smooth out that syntax.

[pjfanning]

Can the error message be more like s"Concat is not supported for unexpected header range implementation type ${range.getClass}"?

[timw]

I've actually switched this over to use JavaMapping.toScala, which is consistent with other param casting in the Scala DSLs.
Let me know what you think.

[pjfanning]

I work prefer to see other contributors' opinion before merging this.

Ideally, the public methods should have javadoc with @since 2.0.0.

[timw]

Ideally, the public methods should have javadoc with @SInCE 2.0.0.

Pushed update with this.