envoyproxy/envoy#2971 adds warning-checks that mutations should be POSTed. This documents that status. In a future PR, mutations will fail if they are not POSTs.
See envoyproxy/envoy#2763 for more detail.
Signed-off-by: Joshua Marantz <jmarantz@google.com>
This unhides request headers to add field for HTTP health check and put a
release note line in the version history.
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
This PR includes the necessary modifications in support of envoyproxy/envoy#2828.
Added additional configuration to ext_authz.proto so that the filter is able to call an HTTP/1.1 authorization service.
In external_auth.proto, added a nested message to CheckResponse that allows the authorization service to pass additional HTTP response attributes back to the authz filter.
Signed-off-by: Gabriel <gsagula@gmail.com>
The current build.sh file will attempt to use the default python version (in my case 3.6) instead of python2.7 which seems to be the required version due to the standard library having removed StringIO from python3.
Signed-off-by: Nicholas Johns <nicholas.a.johns5@gmail.com>
This patch adds info of /stats/prometheus as an alternative endpoint to
get server stats in prometheus format.
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Introduce the concept of locality weighted LB (as distinct from zone
aware LB) in the docs and a new field in Cluster, locality_weighted_lb,
for configuring this behavior.
Signed-off-by: Harvey Tuch <htuch@google.com>
Document the behavior when each option is set to true, set to false,
or unset.
Document that the transparent option should be used in conjunction
the original_dst_filter to restore the original destination address.
Signed-off-by: Romain Lenglet <romain@covalent.io>
Due to there's actually no `HTTP/1.1` with gRPC format link. To avoid misunderstanding, I've adjusted the sequence and placed the **similar** wire format in gRPC over HTTP/2. The updated link is equivalent to wire format link in gRPC guide.
Signed-off-by: Tzu-Chiao Yeh <su3g4284zo6y7@gmail.com>
We are changing the procedure to require contributors to add
release notes directly to this repo as they do changes. It's
too much work for the releaser to transfer them over. I'm
going to do this for 1.6.0 but I'm putting this stub in here
so that any ungoing changes that are going to sneak into 1.6.0
can get added directly.
Signed-off-by: Matt Klein <mklein@lyft.com>
Unhide the request_headers_to_add, response_headers_to_add, and response_headers_to_remove fields in ClusterWeight. Update HTTP conn manager docs related to same.
Doc update for envoyproxy/envoy#2765.
Signed-off-by: Stephan Zuercher stephan@turbinelabs.io
Add a "transparent" option to Listener to set the SOL_IP/IP_TRANSPARENT option on listen sockets, which allows using Envoy with the iptables TPROXY target.
Unlike the iptables REDIRECT target, TPROXY allows preserving both the source and destination IP addresses and ports of accepted connections.
API changes for: envoyproxy/envoy#2719
Signed-off-by: Romain Lenglet <romain@covalent.io>
V1 configuration does not support ip tagging. This pr cleans references to IP Tagging in V1 configs.
Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>
1) Add ability to runtime filter to configure default, divisor, and
whether independent randomness is used.
2) Also add LE to the comparison filter.
Signed-off-by: Matt Klein <mklein@lyft.com>
Updates the L7 IP tagging filter proto, v1 configuration documentation and overview documentation.
Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>
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>