Skip to content
Merged
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions api/lds.proto
Original file line number Diff line number Diff line change
Expand Up @@ -103,6 +103,13 @@ message Listener {

// The type of draining to perform at a listener-wide level.
DrainType drain_type = 8;

// Listener filters have the opportunity to manipulate and augment the connection metadata that
// is used in connection filter chain matching, for example. These filters are run before any in
// :ref:`filter_chains <envoy_api_field_Listener.filter_chains>`. Order matters as the filters
// are processed sequentially right after a socket has been accepted by the listener, and before
// a connection is created.
repeated Filter listener_filters = 9;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a completely different type of filter from network filters, should it use a different type to describe it? Right now they have the same set of data, but possibly in the future they could be different. Prior art: HttpFilter is a different type.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. I would do a ListenerFilter type just in case for future enhancement.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Assuming we don't need the deprecated_v1 stuff, ListenerFilter message now only has the name and config members.

}

message Filter {
Expand Down