Tide: Implement a way to handle CORS headers

Created on 12 May 2019  路  4Comments  路  Source: http-rs/tide

To be able to implement an API with tide, we need to be able to answer OPTION requests with appropriate CORS headers.

Feature Request

Detailed Description

Investigation is needed, but we would probably use the Context API.

We can either integrate handling of CORS in the core of tide, or implement it as a tide-cors crate.

Option 1, integration: CORS is essential to every framework. So integrating it would make sense
Option 2, external crate: In a professional environment, CORS is for example handled via Docker or NGINX, and not directly from the service itself. Therefore it is technically not needed on application level.

Context

Having an option to pull the handling of CORS into your application would make it easier to test it without integrating it in your general systems architecture.

Smaller services would also probably handle CORS directly via the service itself, therefore the user of tide would have a complete environment.

Possible Implementation

Thanks to the input from @prasannavl, we can look at the actix-cors implementation.

Another example implementation (part of it) coud like this this.

Most helpful comment

So, here's what the 800 LOC actix-web impl buys over the super simplified 50-75 LOC impl of surf:

  • Input validations - actix-web is exhaustive taking typed inputs, while surf simply accepts any valid HeaderValue and assumes the user to provide valid header values.

Beyond that, pre-flights requests are handled identically by both. For actual requests, surf impl currently doesn't handle:

  • The case where you echo back the Origin header into ACCESS_CONTROL_ALLOW_ORIGIN
  • ACCESS_CONTROL_EXPOSE_HEADERS
  • ACCESS_CONTROL_ALLOW_CREDENTIALS
  • Setups us origin into Vary header.
  • The case where the cors is actually enforced on the server, i.e, the client makes a request without Origin and the server refuses to serve it (I'm not sure if this is from the W3C spec - have to check - since CORS handling is usually all on the client and server barely cares other setting the right headers)

Fortunately, all of these above should be trivial to add - it really comes down to the excellent validations as the biggest difference.

All 4 comments

surf's CORS module might be a good starting point since it already works with Tide (:

So, here's what the 800 LOC actix-web impl buys over the super simplified 50-75 LOC impl of surf:

  • Input validations - actix-web is exhaustive taking typed inputs, while surf simply accepts any valid HeaderValue and assumes the user to provide valid header values.

Beyond that, pre-flights requests are handled identically by both. For actual requests, surf impl currently doesn't handle:

  • The case where you echo back the Origin header into ACCESS_CONTROL_ALLOW_ORIGIN
  • ACCESS_CONTROL_EXPOSE_HEADERS
  • ACCESS_CONTROL_ALLOW_CREDENTIALS
  • Setups us origin into Vary header.
  • The case where the cors is actually enforced on the server, i.e, the client makes a request without Origin and the server refuses to serve it (I'm not sure if this is from the W3C spec - have to check - since CORS handling is usually all on the client and server barely cares other setting the right headers)

Fortunately, all of these above should be trivial to add - it really comes down to the excellent validations as the biggest difference.

May I work on this?

@k-nasa for sure!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fasterthanlime picture fasterthanlime  路  4Comments

milesgranger picture milesgranger  路  6Comments

kingluo picture kingluo  路  5Comments

asaaki picture asaaki  路  4Comments

cquintana-verbio picture cquintana-verbio  路  6Comments