-
Notifications
You must be signed in to change notification settings - Fork 5.5k
WiP: Local reply mapper #8126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WiP: Local reply mapper #8126
Changes from 16 commits
899ec21
6da905d
8eb6f82
9bf0e6b
fc3c545
c9a686e
4213f2e
f8df3ae
dac4695
052aeeb
1499746
8f022b6
419a59c
468308a
1cce878
1efc2e3
7c75f6c
2670d0f
955bf79
cd31254
a77c82f
20abff0
9c8d757
cc55bb4
7784130
31f3cbf
5eadeca
199dd43
0aee07a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,7 +23,7 @@ import "validate/validate.proto"; | |
| // [#protodoc-title: HTTP connection manager] | ||
| // HTTP connection manager :ref:`configuration overview <config_http_conn_man>`. | ||
|
|
||
| // [#comment:next free field: 35] | ||
| // [#comment:next free field: 36] | ||
| message HttpConnectionManager { | ||
| enum CodecType { | ||
|
|
||
|
|
@@ -453,6 +453,40 @@ message HttpConnectionManager { | |
| // with `prefix` match set to `/dir`. Defaults to `false`. Note that slash merging is not part of | ||
| // `HTTP spec <https://tools.ietf.org/html/rfc3986>` and is provided for convenience. | ||
| bool merge_slashes = 33; | ||
|
|
||
| message LocalReplyConfig { | ||
| // Configuration of list of mappers which allows to filter and change local response. | ||
| // Code iterate through mappers until first match of filter. | ||
| repeated ResponseMapper mapper = 1; | ||
|
|
||
| // Allows to define custom format of local reply. | ||
| oneof reply_format { | ||
| // Response body plain text format. | ||
| string format = 2; | ||
|
|
||
| // Response body json format as dictionary. | ||
| google.protobuf.Struct json_format = 3; | ||
| } | ||
| }; | ||
|
|
||
| // Configuration of local reply returned by Envoy. Allows to specify mapping and format of response. | ||
| LocalReplyConfig local_reply_config = 35; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we think that there might be possibly a use case here for multiple custom format, I'd just allow it in the API; the implementation can probably deal with this without too much complexity. I.e. let's be really sure that one format will be sufficient forever if we take the existing design.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added possibility to define format for each mapper. I think about implementation: if mapper format is defined then use mapper format else use format from config (or default if not defined)
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Given the way you added it, it seems we could punt this until later, if you really want to keep the top-level
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes I thought it might be good idea to define one format at top-level and allow to define custom one for each mapper if someone want different format. I can also remove top level mapper but if someone want to change the format of all responses it will require definition of mapper without
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, given that, maybe just completely ignore the above thread and rollback the per-rewriter bits, since they can be added in a non-breaking way later additively. It'll simplify the implementation work at your end. Sorry about the confusion, the PR clarified how this would look, thanks. |
||
| } | ||
|
|
||
| message ResponseMapper { | ||
| // Filter is used to determine if the response should be changed. | ||
| envoy.config.filter.accesslog.v2.AccessLogFilter filter = 1 [(validate.rules).message.required = true]; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great, if this works I think adding #next-major-version comment in
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, this sounds great. |
||
|
|
||
| // Rewriter defines which values in local reply should be changed. | ||
| ResponseRewriter rewriter = 2 [(validate.rules).message.required = true]; | ||
| } | ||
|
|
||
| // Configuration of new value for matched local response. | ||
| message ResponseRewriter { | ||
| // Status code for matched response. | ||
| google.protobuf.UInt32Value status_code = 1; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can this just be
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it will be good to keep this field optional if in future someone want to add e.g: headers, body. |
||
|
|
||
| // TODO: add support for GRPC rewrite. | ||
| } | ||
|
|
||
| message Rds { | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -14,3 +14,4 @@ HTTP connection manager | |
| stats | ||
| runtime | ||
| rds | ||
| local_reply | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,103 @@ | ||
| .. _config_http_conn_man_local_reply: | ||
|
|
||
| Local reply modification | ||
| ======================== | ||
|
|
||
| The :ref:`HTTP connection manager <arch_overview_http_conn_man>` supports modification of local reply which is response returned by Envoy itself | ||
| rather than response from cluster. | ||
|
|
||
| Features: | ||
|
|
||
| * :ref:`Local reply content modification<config_http_conn_man_local_reply_modification>`. | ||
| * :ref:`Local reply format modification<config_http_conn_man_local_reply_format>`. | ||
|
|
||
| .. _config_http_conn_man_local_reply_modification: | ||
|
|
||
| Local reply content modification | ||
| -------------------------------- | ||
|
|
||
| There is support for modification of local replies. You can specify list of :ref:`mappers <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpConnectionManager.LocalReplyConfig.mapper>` which contains | ||
| pairs of :ref:`filter <envoy_api_msg_config.filter.accesslog.v2.AccessLogFilter>` and :ref:`rewriter <envoy_api_msg_config.filter.network.http_connection_manager.v2.ResponseRewriter>`. Both elements in pair has to be | ||
| specified. If more than one pair is defined then first matching is used. | ||
|
|
||
| Example how to change status code when local reply contains any of these response flags: | ||
|
|
||
| .. code-block:: yaml | ||
|
|
||
| mapper: | ||
| filter: | ||
| response_flag_filter: | ||
| flags: | ||
| - LH | ||
| - UH | ||
| rewriter: | ||
| status_code: 504 | ||
|
|
||
| .. _config_http_conn_man_local_reply_format: | ||
|
|
||
| Local reply format modification | ||
| ------------------------------- | ||
|
|
||
| Local reply format contains command operators that extract the relevant data and insert it. | ||
| They support two formats: :ref:`format strings <config_http_conn_man_local_reply_format_string>` and | ||
| :ref:`"format dictionaries" <config_http_conn_man_local_reply_dictionaries>`. In both cases, the :ref:`command operators <config_http_conn_man_local_reply_command_operators>` | ||
| are used to extract the relevant data, which is then inserted into the specified reply format. | ||
| Only one reply format may be specified at the time. | ||
|
|
||
| .. _config_http_conn_man_local_reply_format_string: | ||
|
|
||
| Format Strings | ||
| -------------- | ||
|
|
||
| Format strings are plain strings, specified using the ``format`` key. They may contain | ||
| either :ref:`command operators <config_http_conn_man_local_reply_command_operators>` or other characters interpreted as a plain string. | ||
| The access log formatter does not make any assumptions about a new line separator, so one | ||
| has to specified as part of the format string. | ||
|
|
||
| .. code-block:: none | ||
|
|
||
| %RESP_BODY% %RESPONSE_CODE% %RESPONSE_FLAGS% "My custom response" | ||
|
|
||
| Example of custom Envoy local reply format: | ||
|
|
||
| .. code-block:: none | ||
|
|
||
| upstream connect error or disconnect/reset before headers. reset reason: connection failure 204 UH My custom response | ||
|
|
||
|
|
||
| If format isn't specified then :ref:`default format <config_http_conn_man_local_reply_default_format>` is used. | ||
|
|
||
| .. _config_http_conn_man_local_reply_default_format: | ||
|
|
||
| Default Format String | ||
| --------------------- | ||
|
|
||
| If custom format string is not specified, Envoy uses the following default format: | ||
|
|
||
| .. code-block:: none | ||
|
|
||
| %RESP_BODY% | ||
|
|
||
| Example of the default local reply format: | ||
|
|
||
| .. code-block:: none | ||
|
|
||
| upstream connect error or disconnect/reset before headers. reset reason: connection failure | ||
|
|
||
| .. _config_http_conn_man_local_reply_dictionaries: | ||
|
|
||
| Format Dictionaries | ||
| ------------------- | ||
|
|
||
| Format dictionaries are dictionaries that specify a structured local reply output format, | ||
| specified using the ``json_format`` key. This allows response to be returned in a structured format | ||
| such as JSON. | ||
|
|
||
| More can be found in :ref:`configuration <config_access_log_format_dictionaries>`. | ||
|
|
||
| .. _config_http_conn_man_local_reply_command_operators: | ||
|
|
||
| Command Operators | ||
| ----------------- | ||
|
|
||
| Local reply format reuse :ref:`access log operators <config_access_log_command_operators>`, so more information can be found there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think something like this belongs in
envoy.type, as it comes up in other places, e.g. access logs. It's basically aStringOrJsontype.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find this type. Maybe it should be added in v3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm suggesting we start the trend by adding it in this PR :) Up to you, at least leave a
[#next-major-version:...]comment if not.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added new format. You can check if it looks ok. I haven't changed it in v2 accesslog config because it isn't compatible with current acceslog format. Example: