v2 api changes: Use oneof to specify header match options, based on value(exact_match), regex or range.
The existing value and regex fields will be deprecated. Use the header_match_specfier oneof instead.
Add a new range.proto (envoy.type.v2) for the range type definition.
The SInt64Range message is defined in envoy.type.v2 range.proto.
It consists of start and end (inclusive, exclusive) sint64 values.
v1 api: Add a range_match object to the route headers json. Presence of this object indicates range based route match.
Example: For the below route config:
{
"prefix": "/",
"cluster": "PartitionB",
"name": "PartitionKey",
"range_match": { "start": 0, "end": 10}
}
In the incoming request, if the PartitionKey header value = 0, route match succeeds. Route match fails if the header value = 10, -10, "somestring".
This feature can be used for request routing with Service Fabric stateful services, to route to the desired partition with the [ranged partitioning scheme](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-partitioning#ranged-partitioning-scheme)
Signed-off-by: Kavya Kotacherry <kavyako@microsoft.com>
There is no way to modify the response of PING on a running Redis server without restarting it. This makes it painful to terminate an instance. All inflight requests plus requests until ejection by active or passive healthcheck will fail.
Signed-off-by: Daniel Hochman <danielhochman@users.noreply.github.com>
Add listener_filter_chain to Listener, which is a list of individual
listener filters that make up the filter chain for sockets accepted
with the listener. These filters are run before any in the
'filter_chains', and these filters have 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.
As an example the functionality controlled by Listener options
'use_original_dst' and 'use_proxy_proto' can be implemented as
listener filters instead of being hard-wired into Envoy's listener
logic. This makes also extensions (like proxy protocol v2) easier to
implement and deploy.
Signed-off-by: Jarno Rajahalme <jarno@covalent.io>
envoyproxy/envoy#2256 adds restrictions to the backing sources for xDS resources. This change documents those restrictions.
Signed-off-by: Jose Nino <jnino@lyft.com>
Make it more discoverable and in prep for adding new content.
Also make the use of "Envoy" in top level titles consistent.
We don't need to say "Envoy" in general as all of the documentation
is about Envoy.
Signed-off-by: Matt Klein <mklein@lyft.com>
1) Do RDS other than rate limit. This is large enough will do that next.
2) Manually order top level in v2 with better titles
3) Random other fixes
Note also that I'm going to manually reorder the protos in some cases in a
follow up so the docs make a bit more sense for a casual reader.
Signed-off-by: Matt Klein <mklein@lyft.com>
I will defer RDS into another PR. I will also do another cleanup
pass over all of this later but want to get most of this in place
first.
Signed-off-by: Matt Klein <mklein@lyft.com>
This should provide an example of how to do the .proto doc linking,
refactoring and constraint addition for the full API.
Signed-off-by: Harvey Tuch <htuch@google.com>
Kavya Kotacherry - MSFT
Daniel Hochman
jrajahalme
Stephan Zuercher
Matt Klein
alyssawilk
Jose Ulises Nino Rivera
Andrew Dunham
Yuval Kohavi
Lizan Zhou
htuch