Cleanup tonic-web cors support and replace it with tower-http

[slinkydeveloper]

Motivation

The CORS code in tonic-web is not 100% compliant with cors spec and cannot be detached from the rest of the tonic-web protocol implementation. This can be problematic for some use cases where the tonic-web layer is just a part of the server, and some other cors layer is used before (as far as i understand in particular for https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).

Some other grpc-web implementations where cors is separate from the protocol implementation:

• https://armeria.dev/docs/server-grpc/#grpc-web
• https://github.com/grpc/grpc-web/blob/35284bfe156fc41bbcdd554ac423a587d93ff8da/net/grpc/gateway/examples/helloworld/envoy.yaml#L30

How

As described here: #1119 (comment). the idea is to:

• Remove all the tonic-web cors handling logic
• tonic_web::enable composes CorsLayer from tonic-http and GrpcWebLayer introduced by Implement tower::Layer for tonic_web::Config #1119. If a user wants more control over the CorsLayer, they can just instantiate manually GrpcWebLayer and compose it with whatever configured cors layer they want (not necessarily the one provided by tower-http)

Breaking changes

• Config gets removed
• Behavioral changes for the cors layer, more conform to the spec

Notes

• The current cors implementation is "strict", returning an error status code when headers, origin and whatnot are not compatible with the cors configuration, e.g.

  tonic/tonic-web/src/service.rs

  Line 300 in b409ddd

  async fn origin_not_allowed() {

• This seems to be the opposite of what should be, see cors: Don't return an error for preflight requests with non-matching origin tower-rs/tower-http#224 and in particular the fetch spec https://fetch.spec.whatwg.org/#http-responses

A successful HTTP response to a CORS-preflight request is similar, except it is restricted to an ok status, e.g., 200 or 204.
Any other kind of HTTP response is not successful and will either end up not being shared or fail the CORS-preflight request.

This because in the preflight request the server just replies back to the browser with its cors configuration, then it's up to the browser to figure out whether it should proceed or not with the actual request.

[LucioFranco]

Ok finally got to reading this and it all makes sense to me!