To be able to implement an API with tide, we need to be able to answer OPTION requests with appropriate CORS headers.
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.
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.
Thanks to the input from @prasannavl, we can look at the actix-cors implementation.
Another example implementation (part of it) coud like this this.
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:
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:
Origin header into ACCESS_CONTROL_ALLOW_ORIGINACCESS_CONTROL_EXPOSE_HEADERSACCESS_CONTROL_ALLOW_CREDENTIALSVary header.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!
Most helpful comment
So, here's what the 800 LOC actix-web impl buys over the super simplified 50-75 LOC impl of surf:
HeaderValueand 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:
Originheader intoACCESS_CONTROL_ALLOW_ORIGINACCESS_CONTROL_EXPOSE_HEADERSACCESS_CONTROL_ALLOW_CREDENTIALSVaryheader.Originand 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.