John Howard
John Howard
I believe this should be fixed by https://github.com/istio/istio/pull/55715
Simply allowing OPTIONS is wrong and a violation of the users intent. ~Every CORS implementation handles **some** OPTIONS requests but not others -- only things that are 'preflight'. What is...
If we want to have specific handling of preflight connections then maybe this is acceptable. That is, an OPTIONS request will either be either...: * Directly returned `200` with CORS...
Yeah I definitely do not think an envoy limitations should lead us to permanently have an API that violates the users configuration in a manner that is potentially unsafe and...
I mean that Envoy cannot do https://github.com/kubernetes-sigs/gateway-api/issues/3857#issuecomment-2970797616 AFAIK. Note OPTION != Preflight, OPTION is a superset of preflight requests.
Yes, a preflight request is that. But that doesn't mean all requests with those properties are a preflight request. Square vs rectangle. At the very least, Envoy does not currently...
I am aware of envoys behavior. Not all Options requests are "preflight" so that flag does not make it safe to allow OPTION
ah my bad I misread the code slightly. The logic is inconsistent with the comments https://github.com/envoyproxy/envoy/blob/00aac598bf87c76a5c8a70bd5f2aea7b8580a76b/source/extensions/filters/http/cors/cors_filter.cc#L125 but it doesn't impact the case when you set *not* forward preflight. But the...
Approved but it has a do-not-merge label
https://github.com/istio/istio/issues/53676 - partially opened link in a TODO in github