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

router: Implement https_redirect in RedirectAction #2479

Merged
merged 9 commits into from
Feb 1, 2018

Conversation

JayH5
Copy link
Contributor

@JayH5 JayH5 commented Jan 30, 2018

Description:
This implements the https_redirect field to RedirectAction to redirect requests to the https scheme.

Risk Level: Low

Low: Small bug fix or small optional feature.

Testing:
Tests added to test/common/router/config_test_impl.cc. I only implemented these for the v2 API. I hope that's ok?

Docs Changes:
envoyproxy/data-plane-api#426

Release Notes:
Added

Jamie Hewland added 2 commits January 30, 2018 17:16
* envoyproxy#2371

Signed-off-by: Jamie Hewland <jamie@praekelt.org>
Signed-off-by: Jamie Hewland <jamie@praekelt.org>
Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

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

Nice change! Only adding this for v2 is totally fine :-)

One thought while I'm in here but otherwise, @junr03 mind doing a first pass for style and I'll do one final pass?

@@ -2171,17 +2171,17 @@ TEST(RouteMatcherTest, DirectResponse) {
"domains": ["redirect.lyft.com"],
"routes": [
{
"prefix": "/foo",
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I'm probably missing something obvious, but why change these?
It's generally helpful when changing code to leave the existing tests as is to make it clear there's no change to existing functionality.

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 seemed to me to be better to have the path prefixes mean something, especially as more kinds of redirects were added.

So there would be...

/host => host_redirect
/path => path_redirect
/host_path => host_redirect + path_redirect
...

...instead of foo/bar/baz which don't mean anything. That was slightly complicated by /host being a prefix of /host_path so ordering matters now 😕.

I can try rework or go back to a minimal change?

Copy link
Contributor

Choose a reason for hiding this comment

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

Fair enough - I'll take a close look at diffs when I do my pass, so please just consider it for future PRs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks 🙏🏼

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the explanation - it is good clean up :-)

Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

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

Looks great overall. I suspect this may have merge conflicts with #2315, mind doing a merge with master?

return fmt::format("{}://{}{}", headers.ForwardedProto()->value().c_str(), final_host,
final_path);
if (https_redirect_) {
final_scheme = "https";
Copy link
Contributor

Choose a reason for hiding this comment

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

minor prefernce for Http::Headers::get().SchemeValues.Https

Copy link
Contributor Author

@JayH5 JayH5 Jan 31, 2018

Choose a reason for hiding this comment

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

Some notes here (which I hope you'll see since GitHub has hidden the thread):

  • I did make this change
  • My C++ is pretty rusty, but I'm not sure why this method uses char* rather than just std::string. Could save a bunch of .c_str()s? It's to prevent copies + the HeaderString type doesn't have an easy way to get a std::string.
  • There is another place in this file where the "https" string literal is used.

config.route(headers, 0)->directResponseEntry()->newPath(headers));
}
{
Http::TestHeaderMapImpl headers =
genRedirectHeaders("redirect.lyft.com", "/bar", true, false);
EXPECT_EQ("https://redirect.lyft.com/new_bar",
genRedirectHeaders("redirect.lyft.com", "/path", false, false);
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking at these more carefully I believe we've lost test coverage that https scheme is preserved in the non-redirect path. Let me know if I'm missing a test, otherwise please leave the tests which previously had true for ssl true?

Jamie Hewland added 3 commits January 31, 2018 10:27
Signed-off-by: Jamie Hewland <jamie@praekelt.org>
Signed-off-by: Jamie Hewland <jamie@praekelt.org>
Signed-off-by: Jamie Hewland <jamie@praekelt.org>
@JayH5
Copy link
Contributor Author

JayH5 commented Jan 31, 2018

It looks like the tests were broken when #2307 was merged.

@alyssawilk
Copy link
Contributor

indeed, sorry, #2490 should fix once it lands.

@htuch
Copy link
Member

htuch commented Jan 31, 2018

Can you merge master to pickup #2490?

Signed-off-by: Jamie Hewland <jamie@praekelt.org>
- match: { prefix: /foo }
- match: { prefix: /host_path_https }
redirect: { host_redirect: new.lyft.com, path_redirect: /new_path, https_redirect: true }
- match: { prefix: /host_path }
Copy link
Member

Choose a reason for hiding this comment

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

based on the previous test coverage on host and path redirect combined, then host and path independently, would it be beneficial to do all chose two combinations here? i.e add the missing host_https path_https redirects?

Jamie Hewland added 3 commits February 1, 2018 09:36
Signed-off-by: Jamie Hewland <jamie@praekelt.org>
Signed-off-by: Jamie Hewland <jamie@praekelt.org>
Signed-off-by: Jamie Hewland <jamie@praekelt.org>
Copy link
Member

@junr03 junr03 left a comment

Choose a reason for hiding this comment

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

lgtm, thanks!

Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

very nice, thank you!

@mattklein123 mattklein123 merged commit 8ca7b57 into envoyproxy:master Feb 1, 2018
Shikugawa pushed a commit to Shikugawa/envoy that referenced this pull request Mar 28, 2020
…xy#2479)

* use different alpn override for different upstream protocol

* update dependent

* address comment
jpsim added a commit that referenced this pull request Nov 28, 2022
Signed-off-by: JP Simard <jp@jpsim.com>
jpsim added a commit that referenced this pull request Nov 29, 2022
Signed-off-by: JP Simard <jp@jpsim.com>
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.

None yet

5 participants