I had been trying to figure out a good way to provide more internally-derived feedback from an *ext_proc* implementation to *envoy* (without needing to do things like set response headers or rely on a separate log file), and was led to the discovery that the `ImmediateResponse.Details` field actually populates `%RESPONSE_CODE_DETAILS%` for use in access logging.
Due to how much better this discovery made my life, I am hoping it will make other people's lives better as well.
Signed-off-by: Chet Nichols III <chet@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ e00aa66429181e3973cc69ca57c26da730cc47af
This makes it possible for a processor to add a body to a request or response that does
not have one, or replace the entire body in the response from a header callback
without otherwise touching it.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c307494627e6f52154c3437fc7aea4c47dce07f0
Commit Message: Support the clear_route_cache parameter on responses
from the remote server
Risk Level: Low. Only enabled if the flag is set.
Testing: New unit test to ensure that the method is called.
Docs Changes: Marked "clear_route_cache" in the API as no longer
"not-implemented".
Release Notes: If the clear_route_cache flag is set on a
response from the external processing server, then the filter will
call the "clearRouteCache" method on the filter state. Processors
should set this flag if they have changed any headers, such as
":path", which may affect routing after the filter runs.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b7ce74e8cc8d882ef23146c5039712e84796950e
Existing trailers will be sent to the processing
server if the processing mode is set to enable them. If the
processing mode is set to sent trailers, but there are no trailers
present, then empty trailers will be sent to the server for
modification.
However, trailers may only be added in the end of the data callback
in Envoy, which may come in before a previous gRPC reply returns.
Filters that need to be able to consistently add trailers where none
existed should enable trailer processing in the Envoy filter
configuration instead of relying on being able to turn it on
dynamically.
Risk Level: Low. Trailers only enabled if a service called by the filter
is configured to ask for them.
Testing: New integration and unit tests added.
Docs Changes: API docs updated in .proto files.
Release Notes:
When the processing mode is changed to SEND
for request or response trailers, a corresponding message will be
sent to the server, which can respond with trailer mutations as desired.
In addition, if trailer processing is enabled in the filter
configuration, then trailer messages will be sent to the server
even if trailers are not present. This makes it possible for the server
to add trailers where none exist.
Finally, at the moment Envoy only implements trailers for the HTTP/2
protocol. Nothing will happen if trailer processing is enabled and
Envoy is using HTTP/1 until Envoy implements trailers for HTTP/1.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 29eb17096e50fc9385edbf260c03da7adc4ca24c
Send request headers to the server and apply header mutations based
on the response. The rest of the protocol is still ignored.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 845f92af869a3aa50856a461265d650ee70d1329
This introduces a new filter called the "external processing filter." It is intended to allow an external service to be able to operate as if it were part of the filter chain using a gRPC stream. It is intended to support a variety of use cases in which processing of HTTP requests and responses by an external service is desired.
A document that describes the filter can be found here:
https://docs.google.com/document/d/1IZqm5IUnG9gc2VqwGaN5C2TZAD9_QbsY9Vvy5vr9Zmw/edit#heading=h.3zlthggr9vvv
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 98d2f3b553b87c3e935f57ba15b4faf68b45d7f0
data-plane-api(Azure Pipelines)