Implement OPTIONS http method about tide HOT 4 CLOSED

Another similar problem involving the same design choice of routing aforementioned:

From the perspective of the semantics of HTTP methods, 405 Method Not Allowed is a better choice over 404 Not Found when there is an endpoint on a specific route path but request methods are not matched.

For example, https://github.com/rustasync/tide/blob/279e0f05a0a24fba9fc192f1d7956ad60fa0cf24/examples/messages.rs#L69
registers POST method on /message. It is supposed to response with 405 Method Not Allowed HTTP status which clearly indicates that the request method is unexpected but the resource (path) is valid.

This behaviour is adhered by most matured Web framework in other programming languages. But it seems that many of the famous Web frameworks in Rust prefer to take the contrary way. There would be some performance penalty to be compliant, but I think it is worth discussing.

Update: The 404/405 problem has been fixed in https://github.com/http-rs/tide/pull/388/files.

from tide.

Just a remark on this (and also to the related PR at #104), it seems that Tide currently stores routes as a HashMap keyed on HTTP method, with values being the routers that contain endpoints with the given HTTP method (and accessed through the URL path).

This is just my idea, but one naive way of adding automatic support for OPTIONS is probably to just key on every available HTTP endpoint (GET/POST/PUT/DELETE/etc.) and see if the route exists at that particular resource. It seems a little inefficient, since in the end we're making a total of at least 7 calls (HEAD exists if GET does, and OPTIONS always exists) as per all of them, but maybe there's a more efficient way of doing this?

That or we somehow keep some other data store inline with the router that keys in the opposite direction, i.e. paths (sans extracted path strings like :id or :name) -> available methods.

from tide.

Any progress on this? It's on the 0.1 milestone, but we're already at 0.6... I'm willing to help out if you point me in the right direction.

from tide.

Note from triage: We handle CORS through the CorsMiddleware; OPTIONS is handled inside the Tide router. We should add docs for this though.

We're unsure however if simplify specifying the middleware also setups the options endpoint; it's been a while. We should make it so that we can enable that. One way to get there is by enabling middleware to run before the router, which is something we may want to do for other reasons as well.

from tide.