direct_response precedence over CORS pre-flight response
#8,262 opened on Sep 16, 2019
Repository metrics
- Stars
- (27,997 stars)
- PR merge metrics
- (Avg merge 8d) (378 merged PRs in 30d)
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.