Skip to content
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

Merged
merged 13 commits into from
Dec 15, 2020

Conversation

esmet
Copy link
Contributor

@esmet esmet commented Dec 4, 2020

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:

@repokitteh-read-only
Copy link

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.

🐱

Caused by: #14276 was opened by esmet.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/envoy/.
API shepherd assignee is @lizan
CC @envoyproxy/api-watchers: FYI only for changes made to api/envoy/.

🐱

Caused by: #14276 was opened by esmet.

see: more, trace.

DataSource text_format_source = 5;

// Specify fixed text with no command operators.
string fixed_text = 6;
Copy link
Contributor

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

Copy link
Contributor Author

@esmet esmet Dec 4, 2020

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.

Copy link
Member

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?

Copy link
Contributor Author

@esmet esmet Dec 4, 2020

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

Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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).

Copy link
Contributor

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.

Copy link
Contributor Author

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]>
@esmet esmet force-pushed the plain-string-formatter-impl branch from d95c3a2 to 4296eee Compare December 4, 2020 19:12
Copy link
Member

@lizan lizan left a 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;
Copy link
Member

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?

@esmet
Copy link
Contributor Author

esmet commented Dec 4, 2020

Sure, makes sense.

qiwzhang
qiwzhang previously approved these changes Dec 7, 2020
@esmet esmet changed the title formatter: add fixed_text and text_format_source formatter: add text_format_source, relax minimum string length on text_format Dec 8, 2020
…text_format

add coverage to local_reply_test

Signed-off-by: John Esmet <[email protected]>
Copy link
Contributor

@qiwzhang qiwzhang left a 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: ""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this removed?

Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks

qiwzhang
qiwzhang previously approved these changes Dec 9, 2020
@lizan
Copy link
Member

lizan commented Dec 9, 2020

can you check CI?

@esmet
Copy link
Contributor Author

esmet commented Dec 11, 2020

can you check CI?

Looks like tests are failing since we deprecated text_format.

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 text_source and relax the inline_string validation in the next PR. What do you think?

@lizan
Copy link
Member

lizan commented Dec 12, 2020

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).

You can still test it by wrapping test name with DEPRECATED_FEATURE_TEST, see how other test does. Deprecating doesn't mean removing tests.

@esmet
Copy link
Contributor Author

esmet commented Dec 12, 2020

Cool let me try that

…o local_reply to cover the deprecated text_format with an empty string

Signed-off-by: John Esmet <[email protected]>
Copy link
Member

@lizan lizan left a 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]>
@esmet esmet requested a review from lizan December 14, 2020 17:57
qiwzhang
qiwzhang previously approved these changes Dec 14, 2020
Copy link
Member

@lizan lizan left a 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: alphabetical order

Copy link
Contributor Author

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]>
@lizan lizan merged commit 43bf707 into envoyproxy:master Dec 15, 2020
@esmet esmet deleted the plain-string-formatter-impl branch December 16, 2020 00:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants