CORS plugin supersedes OPTIONS endpoint mappings

When enabling CORS, adding an endpoint handler for OPTIONS no longer works. Example:

val app = Javalin.create { config ->
  config.enableCorsForAllOrigins()
}.options("/test") { ctx -> ctx.result("test") }

app.start()

curl -X OPTIONS http://localhost:7000/test
# no value for response

Looking at the code, io.javalin.core.util.CorsPlugin adds both a before handler and an endpoint handler (for *). After the endpoint handler runs, the servlet ignores every other possible match for the route.

It is possible to work around this by adding an after handler to the desired path and testing for the OPTIONS method:

val app = Javalin.create { config ->
  config.enableCorsForAllOrigins()
}.after("/test") {
  if (ctx.method() == "OPTIONS") {
    ctx -> ctx.result("test")
  }
}

app.start()

curl -X OPTIONS http://localhost:7000/test
# test

But that feels contrived. I feel at least a warning in the docs about not being able to use OPTIONS endpoint handlers together with the CORS plugin would be nice, but ideally enabling CORS wouldn’t be so intrusive.

With regards to use-cases, RFC 7231 says that “the OPTIONS method requests information about the communication options available for the target resource” . In our case, we wanted to add some metadata to some tricky endpoint payloads, to make the life of API clients easier.

[tipsy]

Yes, you are correct 😃

[tipsy]

No worries, didn’t mean to rush you !