direct_response precedence over CORS pre-flight response
#8.262 geöffnet am 16. Sept. 2019
Repository-Metriken
- Stars
- (27.997 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 8T) (378 gemergte PRs in 30 T)
Beschreibung
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.