After updating our Ktor webservice from Ktor 1.6 to 2.0, we've been having troubles to get the CORS plugin to handle preflight requests correctly. Basically, OPTIONS requests will always be answered with a 405 Method Not Allowed no matter what you do, unless you explicitly specify the options route in your routing plugin. This seems to not be a problem with the CORS plugin itself, but rather a side effect of this issue being solved, which prevents the CORS plugin from ever being called for OPTIONS requests to a route where no options handler is installed, but another method handler exists. Is there a recommended workaround for that? The only solution I've found so far that fixes this for all routes without specifying an explicit options handler for each one individually is adding this generic catch-all handler to the top level routing:

options("{...}") { }

But that feels like a hack, and I'm not even sure it doesn't produce unwanted side effects, even though CORS seems to work correctly with it. Isn't there a way to let CORS handle preflight requests fully automatically without having to add this?

Could you please share a code snippet for the server and an example request to reproduce your issue?

Sure, it's actually really simple to reproduce. Use this code for the server:

fun main() {
    embeddedServer(Netty, port = 8080) {
        install(CallLogging)
        routing {
            install(CORS) {
                anyHost()
                allowMethod(HttpMethod.Put)
            }
            // options("{...}") { }
            put("test") {
                call.respond("Hello World")
            }
        }
    }.start(true)
}

And then try to run this request against it:

OPTIONS <http://localhost:8080/test>
Access-Control-Request-Method: PUT
Origin: <https://example.com>

With ktor 2.0.2, this gives me a 405, where I would have expected it to give me a 200. If you remove the

allowMethod

call, I would instead expect a 403, but again, 405. If you uncomment the

options

handler, then it works fine. In creating this reproduction snippet I now noticed that installing the CORS feature globally, instead of inside the routing, it works properly even without the additional

options

handler. However, in our production app that's not a solution for us because we do need different CORS handling depending on the route and installing CORS both globally as well as into a specific route throws an error on startup that this is not a supported use case.

Thank you for explanation. I’ve created an issue to address this problem.

Thank you!

You can install the

CORS

plugin into an application instead of a routing to solve your problem.

Yeah, I did figure out that that solves the issue in the reproduction example, but we do need different CORS handling for different routes in our production app, so that doesn't work for us. The workaround with specifying the catch-all

options

handler works well enough for us for now though until this is fixed, we'll keep a close eye on if something doesn't work right with that.