Status Update
Comments
[Deleted User] <[Deleted User]> #2
al...@einride.tech <al...@einride.tech> #3
I attempted to use an external load balancer in front of the API Gateway as has been suggested in some places. I added the necessary headers on the response coming from the API Gateway to avoid CORS however while it solves the issues with the missing CORS headers, it does not work with OPTIONS requests as the API Gateway does not understand the request and returns a 404 and the browser doesn't care if there are headers or not and just says it is a CORS error as it expects a 200.
Redirecting the OPTIONS request to some dummy service that returns 200 might work however you need some way to redirect all OPTIONS requests (since you don't really have control over the underlying browser functionality on when and where it decided it needs to send an OPTIONS request) and I did not see a way to do that with the load balancer so using an external load balancer.
This makes API Gateway nearly impossible to use if you have a backend gRPC with a REST frontend
os...@einride.tech <os...@einride.tech> #4
Any indication on the priority / timeline of when this would be supported?
We're back to Cloud Endpoints and ESPv2 for the time being, but we 100% see the benefits of the managed API Gateway, should CORS support be available for gRPC requests.
di...@google.com <di...@google.com> #5
By reading through your request, it does seems like a valid feature request to me. Therefore, I am reporting your request to Google Cloud Platform's Networking team for further review. However, I am unable to provide you with an ETA, nor guarantee its implementation at this point of time but rest assured that your feedback is taken very seriously and it is greatly appreciated, as it helps us improve our products.
We don't immediately triage new feature requests. Instead, we wait for a feature to have a handful of stars and, hopefully, comments from several users about how the feature would be useful. Also, you can learn more about the feature request and how we handle it at our end from this link [1].
I recommend visiting this thread to be able to check the progress of issue and feel free to add any information(such as your use-case scenario) which will be helpful.
[1]
os...@einride.tech <os...@einride.tech> #6
Awesome, thank you! Fingers crossed! 🤞
[Deleted User] <[Deleted User]> #7
[Deleted User] <[Deleted User]> #8
lo...@gmail.com <lo...@gmail.com> #10
Bumping this;
Per the discussion linked
Hello Zion, We have a change to our plans for delivering this feature in API Gateway. At the moment we do not have plans to add support for CORS in API Gateway. I apologize for any inconvenience this caused to your plans for adoption of the service.
That makes API Gateway a poor option for webapps when compared to ESPv2 - if you have to manually manage OPTION calls, what is the point of a 'fully managed service'? CORS support & configuration is a critical component to any webapp, and until that necessary feature is added, API Gateway is both incomplete and a not a service I feel comfortable recommending. I highly encourage the priority of this feature to be increased, as I think the rest of it is great - but this feature missing makes it the wrong choice over ESPv2
pr...@exponent.ai <pr...@exponent.ai> #11
Pretty trivial to automate, why it is not included in the startup docs is beyond me.
Description
As discussed in the Cloud Endpoints User Group, it's currently not possible to configure CORS for the fully managed API Gateway.
The suggested workaround to handle OPTIONS headers in the downstream service(s) is not possible when using API Gateway with gRPC backends.
In practice, this makes API Gateway an impractical choice for gRPC users. At my current company, we would like to migrate from Cloud Endpoints to API Gateway, but are holding off migration until support for basic CORS configuration makes it feasible.
I'm creating this public issue so that we and other gRPC users can track progress toward CORS support.
Cheers!