timw opened a new pull request, #940: URL: https://github.com/apache/pekko-http/pull/940
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](https://github.com/apache/pekko-grpc/blob/df65ad955dc0dfc8d563eac6b959046a04590bb4/runtime/src/main/scala/org/apache/pekko/grpc/scaladsl/WebHandler.scala#L35C7-L35C26), 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
