Skip to content
Merged
Changes from 4 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;

// A list of individual listener filters that make up the filter chain for sockets accepted with

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This sentence is a bit hard to read. Obviously this is a list of filters. What I want to know when should use use them and what action they would perform? How are they different from other filters.

If I guess correctly, this is a list of filters attached to socket listener. They do something before the listener accepts a connection.

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.

Your guess would be almost correct. The rest of the comment states that these filters are run right after the listener accepts a connection (in the sence of the accept() system call).

I've reworded to the comment to not state the obvious and come to the point in the first sentence. Please have a look.

// the listener. These filters are run before any in the 'filter_chains', and these filters have

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.

Optional: you could refer to the filter_chains field via:

:ref:`filter_chains <envoy_api_field_Listener.filter_chains>`

// the opportunity to manipulate and augment the connection metadata that is used in connection
// filter chain matching. 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