Description
Title: disable specific http filter by default
Description:
The continuous work of #27210.
In the gateway scene, we may have dozens filters in the http filter chain and have thousands routes. A typically multiple tenants/teams gateway will disable most filters by default and let users to enable part of them for specific route/domain.
In the #27210, we added a disabled flag in the route config to disable a specific http filter in specific route/domain/route config.
To achieve target of above scene, we can mark all filters (except the necessary filters like router) as disabled in the RouteConfiguration.typed_per_filter_config. And then, we can enable part of these filters for specific route or vh by typed_per_filter_config in the route/vh. This should be a feasible solution.
But not sure if it would be better to add a explicitly flag in the HttpConnectionManager.v3.HttpFilter to disable a filter by default?
If a explicitly flag is added, the finally HttpFilter API would be like:
message HttpFilter {
option (udpa.annotations.versioning).previous_message_type =
"envoy.config.filter.network.http_connection_manager.v2.HttpFilter";
reserved 3, 2;
reserved "config";
// The name of the filter configuration. It also serves as a resource name in ExtensionConfigDS.
string name = 1 [(validate.rules).string = {min_len: 1}];
oneof config_type {
// Filter specific configuration which depends on the filter being instantiated. See the supported
// filters for further documentation.
//
// To support configuring a :ref:`match tree <arch_overview_matching_api>`, use an
// :ref:`ExtensionWithMatcher <envoy_v3_api_msg_extensions.common.matching.v3.ExtensionWithMatcher>`
// with the desired HTTP filter.
// [#extension-category: envoy.filters.http]
google.protobuf.Any typed_config = 4;
// Configuration source specifier for an extension configuration discovery service.
// In case of a failure and without the default configuration, the HTTP listener responds with code 500.
// Extension configs delivered through this mechanism are not expected to require warming (see https://github.com/envoyproxy/envoy/issues/12061).
//
// To support configuring a :ref:`match tree <arch_overview_matching_api>`, use an
// :ref:`ExtensionWithMatcher <envoy_v3_api_msg_extensions.common.matching.v3.ExtensionWithMatcher>`
// with the desired HTTP filter. This works for both the default filter configuration as well
// as for filters provided via the API.
config.core.v3.ExtensionConfigSource config_discovery = 5;
}
// If true, clients that do not support this filter may ignore the
// filter but otherwise accept the config.
// Otherwise, clients that do not support this filter must reject the config.
bool is_optional = 6;
// If true, the filter is disabled by default and the filter creation will be skipped except it's
// enabled explictly by configured per filter config in the ``typed_per_filter_config`` of route
// config.
//
// A disabled filter will be treated as enabled explictly in following cases:
//
// 1. Valid per filter config is configured in the ``typed_per_filter_config`` of route config.
// 2. :ref:`FilterConfig <envoy_v3_api_msg_config.route.v3.FilterConfig>` is configured in the
// ``typed_per_filter_config`` of route config and the
// :ref:`disabled of FilterConfig <envoy_v3_api_field_config.route.v3.FilterConfig.disabled>`
// is set to false.
//
// .. note::
// This field only make sense for the downstream HTTP filters for now.
bool disabled = 7; // New flag here.
}
[optional Relevant Links:]
Any extra documentation required to understand the issue.