direct_response precedence over CORS pre-flight response
#8 262 ouverte le 16 sept. 2019
Métriques du dépôt
- Stars
- (27 997 stars)
- Métriques de merge PR
- (Merge moyen 8j) (378 PRs mergées en 30 j)
Description
When using direct_response, it seems to take effect with higher precedence than the envoy.cors filter, even if envoy.cors is first in the http_filters list.
My http config is essentially:
http_filters:
- name: envoy.cors
- name: envoy.filters.http.jwt_authn
config: { ... }
- name: envoy.router
route_config:
virtual_hosts:
- cors: { ... }
...
routes:
- match: { path: "/ping" }
direct_response: { status: 200 }
If I change direct_response to a route to a dummy cluster, a pre-flight OPTIONS request returns the right cors response, but with direct_response the response is the vanilla 200 even for the pre-flight request. It's possible to use a header method match to manually construct a different response for OPTIONS vs other requests to that route, but ideally there would be a way to configure a route action to be a direct response that acts on the request after cors (and other filters) have done their work.
The use case here is e.g. a /ping endpoint that goes through the filter stack and sends a direct response after validating the JWT etc.