This is a followup to #3841, where we introduce HCM-wide stream idle timeouts. This has two effects:
1. We can now timeout immediately after stream creation, potentially before receiving request headers and routing.
2. A default timeout can be configured across all routes. This is overridable on a per-route basis.
The default and overriding semantics are explained in the docs. Also added as a bonus some docs
about how timeouts interact more generally in Envoy.
Fixes#3853.
Risk Level: Low. While there is some change to the per-route vs. HCM wide semantics for stream idle
timeouts, it's not anticipated this feature is in common use yet (it's only a couple of days since
landing), and the caveats in #3841 with the new 5 minute default timeout should already apply.
Testing: Unit/integration tests added.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 672083c7ba4e92fe9548252c45d84d583a95102d
Fixes#1778.
Risk level: Medium. A very conservative 5 minute default idle timeout has been set, which should not affect most deployments with default timeout already kicking in for connection idle or upstream idle. This will however affect things like hanging POSTs.
Testing: Integration and unit tests added for various timeout scenarios.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 45fe83e4eb5344afd1d6a7b0017570ab459f4877
adds the required visibility rules and delegates the rest to the generic
api_proto_library. I tested the change by doing the following without
getting errors.
./ci/run_envoy_docker.sh './ci/do_ci.sh docs'
I changed the BUILD files using the following commands.
/envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/api_proto_library(/api_proto_library_internal(/g'
envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/"api_proto_library"/"api_proto_library_internal"/g'
Signed-off-by: mickey <mickeyju@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4b871c0ab9350882271a490adcee44e613ed9807
*Risk Level*: None
*Testing*: bazel test //test/...
*Docs Changes*: n/a
*Release Notes*: n/a
Found with buildifier.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0e8964c83f359916ecbf9c01a03ade3c92aac479
This enables configuring Envoy to generate cookies that expire at the
end of a session instead of requiring them to have an explicit max-age.
Risk Level: Low
Testing: added unit tests and an integration test
Docs Changes: documented new behavior in API and release docs
Release Notes: router: allow cookie routing to generate session cookies.
Signed-off-by: Alex Konradi <akonradi@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 396f52de26e8864dbbefa903ff605bd52af11b3e
* WebSocket: allow configuring idle timeout and reconnects.
This also resolves a TODO in TcpProxy by always passing it a
configuration, even in the WebSocket case.
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ c755c0393d8d6fbb16a00c7f2b97b8d0d5478c03
docs: clarify the use of "/" as a prefix_rewrite
This patch clarifies the use of "/" as a prefix_rewrite in route and redirect prefix rewriting. And also a note on the use of trailing slashes as match value.
Risk Level: Low
Testing: add more input samples to RedirectPrefixRewrite test.
Docs Changes: Update route.proto doc regarding path_rewrite both for redirect and route.
Release Notes: N/A
Fixes#2956
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Mirrored from https://github.com/envoyproxy/envoy @ d20c12df24845e4745682419edbe1add5b4688b1
Added protos to support Role Based Access Control in Envoy.
Also removed existing auth.proto because the new RBAC proto is a replacement of it.
Ealier discussions at
envoyproxy/data-plane-api#586.
Signed-off-by: Limin Wang <liminwang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 13de384ab34428af99c53201f6b3c95991b7ae10
This patch begins addressing #540, adding per_filter_config fields to both VirtualHost. ClusterWeight and Route configs. A following PR will, as an initial PoC/example, implement vhost/route specific configs for the HTTP buffer filter.
Signed-off-by: Chris Roche <croche@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
This enables generating generic service stubs for all the data-plane-api
proto services when generating Java classes with protoc.
This is generally not needed when implementing a gRPC server but in our case we're implementing
it behind our legacy protobuf RPC framework which rely on these stubs. As far as I know the only negative
with enabling these is generating some potentially unnecessary Java classes.
Signed-off-by: Snow Pettersen <snowp@squareup.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>
this patch adds support for dynamically generating redirect msg based on
a request received by modifying the matched prefix or path.
ref: envoyproxy/envoy#2343
Signed-off-by: Madhavan Balasubramanian <bmadhavan@ebay.com>
I went through and reorganized things to make the v2 docs more
human browsable. I also did a few misc cleanups. There is a lot
more to do here which I'm hoping to find a contractor to pay to
work on, but this is a step in the right direction.
Signed-off-by: Matt Klein <mklein@lyft.com>
There are several main changes in this PR:
Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos.
Create individual packages for each filter and add independent versioning to each filter.
Add visibility constraints to prevent formation of dependency cycles.
Add gogoproto annotations to improve go code generation.
After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package.
The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane).
Added a few gogoproto annotations to improve golang code generation.
Signed-off-by: Kuat Yessenov <kuat@google.com>
Update documentation to match implementation in envoyproxy/envoy#2440.
Makes the WeightedCluster.total_weight field visible in documentation. Update ClusterWeight.weight and traffic shaping document to match.
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>