Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement OPTIONS http method #51

Closed
tzilist opened this issue Nov 19, 2018 · 4 comments
Closed

Implement OPTIONS http method #51

tzilist opened this issue Nov 19, 2018 · 4 comments
Labels
design Open design question
Milestone

Comments

@tzilist
Copy link
Contributor

tzilist commented Nov 19, 2018

This is a pretty common http method when using javascript's fetch api with CORS enabled. I think Tide should probably be able to automatically be able to handle this based on what routes are set and what corresponding methods are available.

@aturon aturon added the design Open design question label Nov 19, 2018
@aturon aturon added this to the 0.1 Release milestone Nov 25, 2018
@tzilist tzilist mentioned this issue Dec 4, 2018
8 tasks
@fairingrey
Copy link
Contributor

fairingrey commented May 4, 2019

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.

@Gowee
Copy link

Gowee commented May 27, 2019

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.

@malte-v
Copy link

malte-v commented Mar 24, 2020

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.

@yoshuawuyts
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Open design question
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants