direct_response precedence over CORS pre-flight response

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.