-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
formatter: add text_format_source, relax minimum string length on text_format #14276
Conversation
Hi @esmet, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
DataSource text_format_source = 5; | ||
|
||
// Specify fixed text with no command operators. | ||
string fixed_text = 6; |
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.
what is the purpose of this format? Especially how it is used in file_access_log
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.
That's a good question and I realize now that I forgot to call out the original motivation for this PR. I linked #14221 as context.
The idea here is that we want a generic way to define HTTP response body rewrites. One interesting use case is to replace a non-empty HTTP body with an empty one, or one with a fixed string, like "denied". We'd use this in both the response_map
(PR above) and the local_reply
config.
One clear alternative to fixed_text
is to relax the minimum length validation on text_format
so that it supports an empty string.
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.
Yeah as I said in #14221, I prefer just relax the text format validation. Will we see performance improvement of this formatter over the normal text_format?
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.
Great. I will relax the format validation and remove fixed_text.
re: performance, I think it stands to reason that fixed format would perform better for that use case but I don't currently have any data to say whether it will matter in practice
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.
This is polluting SubstitutionFormatString class. I see 1) DataSource
of text_format
and 2) fixed_text
should not be part of this SubstitutionFormatString class. They should be in the ResponseMapper message in #14221
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.
While I think it could be correct to specify a DataSource
field in the ResponseMapper
message in #14221, I also think it's reasonable and correct to allow for the text_format
to come from a DataSource
on SubstitutionFormatString
, since a DataSource
supports basic strings (via inline_string
). The semantics of SubstitutionFormatString
remain the same, we just have a behavioral extension that allows it to come from a source, which is nice. What do you think about the tradeoff of having the additional behavior here versus having users of this class define their own DataSource field to replace it?
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 there's also a reasonable argument to be made that the implementation of a SubstitutionFormatString
using a DataSouce
field was really straightforward. To move the source up a layer of abstraction, we'd need the option of creating a format string by telling it where it is sourced from. This conflicts with the existing fields in the format string that tell it where it is sourced from (i.e. text_format and json_format).
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.
It is an interesting idea of replacing json_format
with text_format
.
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.
Now that I think about it, though, json_format
strings are escaped for json while text_format
strings are not. That's fairly important and prevents us from totally getting rid of the json_format
field in favor of text_format
until we have a way to guarantee that json-as-text can be escaped nicely. Maybe we could add/extend the command operator(s) to support escaping?
…FormatString` This commit also adds PlainStringFormatterImpl to implement `fixed_text` Signed-off-by: John Esmet <[email protected]>
d95c3a2
to
4296eee
Compare
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.
Please don't force push, it will screw up review history.
DataSource text_format_source = 5; | ||
|
||
// Specify fixed text with no command operators. | ||
string fixed_text = 6; |
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.
Yeah as I said in #14221, I prefer just relax the text format validation. Will we see performance improvement of this formatter over the normal text_format?
Sure, makes sense. |
…text_format add coverage to local_reply_test Signed-off-by: John Esmet <[email protected]>
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.
Need to fix tests.
default_value: 404 | ||
runtime_key: key_b | ||
body_format_override: | ||
text_format: "" |
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.
Isn't this removed?
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.
it's now deprecated, but not removed. since I removed the validation, I wanted to make sure there was a test case to cover the empty string case.
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 see. Thanks
can you check CI? |
Looks like tests are failing since we deprecated How about we postpone the deprecation to another PR? This will allow us to move forward. If we do deprecate in this PR, then we'll need to update all of the tests to use inline_string, but then we won't be able to test the empty string case because we haven't related validation there (yet). So, maybe we should deprecate both |
You can still test it by wrapping test name with |
Cool let me try that |
Signed-off-by: John Esmet <[email protected]>
…o local_reply to cover the deprecated text_format with an empty string Signed-off-by: John Esmet <[email protected]>
Signed-off-by: John Esmet <[email protected]>
Signed-off-by: John Esmet <[email protected]>
Signed-off-by: John Esmet <[email protected]>
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.
Thanks, this code LGTM, can you add release note? Need a line in deprecated section.
Signed-off-by: John Esmet <[email protected]>
Signed-off-by: John Esmet <[email protected]>
Signed-off-by: John Esmet <[email protected]>
Signed-off-by: John Esmet <[email protected]>
…ter-impl Signed-off-by: John Esmet <[email protected]>
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.
LGTM moduolo one nit. Thank you!
@@ -91,6 +93,7 @@ New Features | |||
|
|||
Deprecated | |||
---------- | |||
* formatter: :ref:`text_format <envoy_v3_api_field_config.core.v3.SubstitutionFormatString.text_format>` is now deprecated in favor of :ref:`text_format_source <envoy_v3_api_field_config.core.v3.SubstitutionFormatString.text_format_source>`. To migrate existing text format strings, use the :ref:`inline_string <envoy_v3_api_field_config.core.v3.DataSource.inline_string>` field. |
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.
nit: alphabetical order
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.
Done!
Signed-off-by: John Esmet <[email protected]>
This change is motivated by #14221 where we use a SubstitutionFormatString as a way to define custom HTTP response body rewrites.
Commit Message: formatter: add text_format_source, relax minimum string length on text_format in SubstitutionFormatString
Additional Description: The relaxed field validation on text_format now allows a user to replace something with nothing, e.g. to replace a non-empty HTTP response body with an empty one. The text_format_source field allows for a DataSource to be used to supply text inside of providing it inline.
Risk Level: low (new fields)
Testing: unit test needed for text_format_source
Docs Changes: NEEDED
Release Notes: NEEDED
Platform Specific Features: