move LowerCaseString to common for common use#16539
move LowerCaseString to common for common use#16539wbpcode wants to merge 7 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: wbpcode <comems@msn.com>
|
/retest |
|
Retrying Azure Pipelines: |
|
It seems clang_tidy simply wants a cleaner constructor here; |
Signed-off-by: wbpcode <comems@msn.com>
|
/retest |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
|
@lizan I think this PR is ready for review. 😃 |
| std::string string_; | ||
| }; | ||
|
|
||
| template <bool (*V)(absl::string_view)> class ValidatedLowerCaseStr : public LowerCaseStrBase { |
There was a problem hiding this comment.
I'm not sure why we need this to be a template.
There was a problem hiding this comment.
@lizan Because I want to get a protocol-independent lower case string and be able to set a different validator. The template is used so that the validator can be pluggable.
Here are some discussions about this question in original PR #16049.
@jmarantz #16049 (comment)
There was a problem hiding this comment.
OK I see, then this should be commented why it is template. and in Http, it should be named like validateHttpLowerCaseString.
There was a problem hiding this comment.
TBH my recollection from the.other PR is that there are a few jumbled concepts here and I want to just quickly mention my line of thinking.
IMO if you really need a validator, forget whether there's a compelling reason to prefer
- template
- virtual method
- function-pointer
But if we do use a function-pointer then in IMO it could be a std::function rather than a templatized function pointer.
Also I think once we are plugging in validation, there's no compelling reason to use LowerCaseString just for Tracing's sake, unless there's something about Tracing that wants strings to be lower-cased. IDK whether that's the case.
That said, I have no fundamental objection to moving LowerCaseString to common as long as it doesn't make anything slower for HTTP headers, which are performance critical.
I don't understand why LowerCaseString has to be paired with a validator though. Can't you just leave LowerCaseString exactly like it is, and move it out of http into common? That seems like a legitimate concept on its own. You could make another layer that adds validation if this is helpful in some way.
There was a problem hiding this comment.
@lizan I will add some new comments to explain why we need this template. 👌
In Http, I kept the original LowerCaseString name so as not to affect the existing code as much as possible. After all, the name Http::LowerCaseString is already widely used. 🤔
There was a problem hiding this comment.
- First, about the performance: This modification will not affect the performance of Http::LowerCaseString since there is no new logic. The introduction of templates may increase the compilation overhead slightly.
- Second, about the relationship between validator and LowerCaseString: I provide a class
LowerCaseStrBaseas a common implementation of LowerCaseString which with no any validation and can be used directly. Then I provideValidatedLowerCaseStrtemplate just as a helper for who wants to add validation to LowerCaseString, for example, Http.
So that means I've got two layers as you think. One layer is the plainLowerCaseString, and the second layer is theValidatedLowerCaseStrthat can mount a different validator.
There was a problem hiding this comment.
@jmarantz At the source code level, it is move. I just kept the previous name LowerCaseString instead of renaming it to ValidatedHttpLowerCaseString or something like that to make PR clean.
using LowerCaseString = Envoy::ValidatedLowerCaseStr<validHeaderString>;
One of the key reasons Trace needs LowerCaseString is performance. But that can be discussed in the new PR.
This PR doesn't really have anything to do with Trace so far. Although the cause is Trace, for now this PR can be seen as a PR that simply strips LowerCaseString out of Http to make it more generic.
There was a problem hiding this comment.
OK...sorry, TBH I'm skeptical about the overall strategy and also concerned there may be overhead added to http headers.
But for the moment maybe it'd be better to focus on strategy. Do you want to describe the high level of what you are trying to achieve in a bug or a google doc? It might be easier to iterate there.
There was a problem hiding this comment.
Thanks for you comments and patience. @jmarantz
In the original PR #16049, there is the high level design of the general tracing. And I remember I had a more detailed discussion with you in slack earlier.
For now, I think we can try to focus on this PR first. Because this PR don't involve the design of the new general tracing yet, just some pre-work. This is also the reason why I split the original PR into multiple PRs.
I think we can discuss the design of general tracing in detail in the new PR (One or two weeks after the completion of this PR).
For this PR I think the most important points are the following:
- whether the PR is clean or not.
- whether the PR is able to keep the existing functionality working.
- whether the PR can guarantee that the existing performance is not affected.
- Whether the PR achieves its purpose: to strip LowerCaseString from Http and get a general LowerCaseString.
There was a problem hiding this comment.
I think PR is probably OK but I'll let Lizan review the details. It'd be better not to do it unless it's needed though.
I am not understanding why you need lower-case semantics at all for the new tracers. There may be a good reason but it's not clear. Iterating in a doc may be easier, rather than this PR.
Signed-off-by: wbpcode <comems@msn.com>
|
/retest |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
|
@lizan Some comments are added. I personally think it might be better to keep the name |
| opentracing::expected<void> Set(opentracing::string_view key, | ||
| opentracing::string_view value) const override { | ||
| Http::LowerCaseString lowercase_key{key}; | ||
| Http::LowerCaseString lowercase_key{{key.data(), key.size()}}; |
There was a problem hiding this comment.
should this be moved to a different PR? Doesn't seem like this should be needed in this one.
| std::string string_; | ||
| }; | ||
|
|
||
| template <bool (*V)(absl::string_view)> class ValidatedLowerCaseStr : public LowerCaseStrBase { |
There was a problem hiding this comment.
I think PR is probably OK but I'll let Lizan review the details. It'd be better not to do it unless it's needed though.
I am not understanding why you need lower-case semantics at all for the new tracers. There may be a good reason but it's not clear. Iterating in a doc may be easier, rather than this PR.
|
Here is a more detailed doc for general tracing. https://docs.google.com/document/d/1gxk5vfHl-Gt3wiNZ-f46Dwmk2NFiEzFJQugmZmpSXk8/edit?usp=sharing |
|
Personally, I still think this PR is actually not that closely related to general tracing. |
|
@wbpcode agreed. This PR seems like a good one to apply if we need such a semantic in the future. There's nothing wrong with moving it, and this PR would be a good start to do that. But I'm not sure if there'd be any more users at this point, so maybe we can put this one on hold till then? And I still think your C-style function-pointer based validation could (a) be a separate PR from the move and (b) could be a lambda for easier use in some cases. |
|
/wait |
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Signed-off-by: wbpcode comems@msn.com
This PR moved
Envoy::Http::LowerCaseStringto common so that other modules can implement case insensitive string comparison without deps on Http.This PR is second sub PR of #16049.
Commit Message:
Additional Description:
Risk Level: Low
Testing: N/A
Docs Changes: N/A
Release Notes: N/A