OPTIONS request handling for cors

[happysalada]

On a cors request the browser sends an OPTIONS request to check for the cors header.
How can I respond to the OPTIONS request. I couldn't find a method on the router for it.
https://docs.rs/trillium-router/0.1.0/trillium_router/struct.Router.html
I tried using any but it didn't work. Perhaps there is a way I haven't found yet?
Or is it just waiting adding an Options here ? https://docs.rs/trillium-router/0.1.0/src/trillium_router/router.rs.html#138
Just curious.

[prabirshrestha]

Beside OPTIONS other methods such as CONNECT, PROPFIND, MLCOL should also be exposed. Options is common enough that I think it makes sense to be first class but other could be treated with router.method() similar to tide.

pub fn method(&mut self, method: http_types::Method, ep: impl Endpoint<State>) -> &mut Self;

[jbr]

I don't think I'll be exposing methods other than the current ones in the router. People can always write their own routers or fork the router if they need niche behavior. Unlike with tide, the trillium router doesn't have to support every possible use case.

I'm not sure about CONNECT, though — I need to think through use-cases. I don't think it makes sense to mount a handler on a CONNECT route, but maybe there should be a CONNECT-specific handler

[happysalada]

Perhaps including them in the any handler then? (just a thought)

[jbr]

I think generally I'd want to talk through the use case for the other methods and try to understand if they're use case I want to support in the router library. Trillium itself supports any method that's in the http_types::Method enum, but the router is currently built intended for rest/crud type applications. It's quite easy to make a new router for a different purpose, and if there's another common use case that involves a different set of methods, it might merit that.

OPTIONS specifically will probably be handled invisibly by the router, and I'm still not sure I understand the CONNECT use case, but it sounds more like a handler of its own than something the router would need to support

[jbr]

Currently this is not supported, but is on the list of high-priority functionality. I'm not sure what the implementation will look like, but I've opened #63 to track this issue.

[happysalada]

Thanks!

[jbr]

@happysalada, @prabirshrestha Options handling has been added in [email protected] — there is both a default OPTIONS response that uses the route table to send the correct allowed methods for a given request path, and the ability to add a route for an arbitrary http method, including OPTIONS, which overrides the default behavior. It is also possible to disable the default OPTIONS handling

[happysalada]

Works beautifully!
Here is how I used the new version of the library

async fn handle_graphql_options(conn: Conn) -> Conn {
    conn.ok("All good")
        .with_header(("Access-Control-Allow-Origin", "*"))
        .with_header(("Access-Control-Allow-Headers", "content-type"))
}

(router initialisation has been omitted)

        Router::new()
            .with_route("OPTIONS", "/graphql", handle_graphql_options),

For cors you need both the allow-origin and allow-header parts (I'm sure everybody knows, but just in case it helps).

[jbr]

Ahh! I have a different solution for CORS coming up soon that will send those headers for all methods, instead of using the router for that

[jbr]

I think even without the cors handler that's coming up, you should be able to remove the .ok("All good") and run that handler before the router in a tuple, like

async fn cors(conn: Conn) -> Conn {
    conn.with_header(("Access-Control-Allow-Origin", "*"))
        .with_header(("Access-Control-Allow-Headers", "content-type"))
}

trillium_smol::run((
    Logger::new(),
    cors,
    Router::new().get("/graphql", …)
));

[happysalada]

Working beautifully! Thank you!