Redirect: default HTTP->HTTPS redirect does not work if envoy is deployed on non-default host ports

[sudeeptoroy]

http redirect url is not composed correctly when envoy is deployed on non standard hostport (!80, !443).
Deployment steps:

1. Reference deployment: https://github.com/heptio/contour/blob/master/examples/ds-hostnet-split/03-envoy.yaml
2. Change hostports to different value; example:
   - containerPort: 80
   hostPort: 8000
   name: http
   protocol: TCP
   - containerPort: 443
   hostPort: 6443
   name: https
   protocol: TCP

developer's steps:

1. Create ingressroute with redirect enabled for the http url; use wildcard
2. Curl url
   Example: curl -L http://redirect-example.com:8000

Issue:
Redirect 301 is received with a wrong redirect port.
example
Received redirect url: https://redirect-example.com:8000
Expected url: https://redirect-example.com:6443

Environment:

• Contour version: all

[stevesloka]

Hey @sudeeptoroy, did you also change the ports that Envoy is configured to listen on? Here are the places you'd need to match: https://github.com/heptio/contour/blob/master/examples/ds-hostnet-split/03-contour.yaml#L36-L37

[sudeeptoroy]

yes, these changes were done too..

[sudeeptoroy]

https://github.com/envoyproxy/envoy/blob/feb56a1f8ee2cf1ea2048e20b7ba05f8199355c6/api/envoy/api/v2/route/route.proto#L954

this seems to be missing while programming the envoy configuration for redirect

[stevesloka]

Ahh, I'm following now @sudeeptoroy, yes, looks like we'd need to configure that setting for this to work properly.

[davecheney]

@sudeeptoroy thank you for raising this issue. I believe that this should be possible to fix without having to add knowledge of the port envoy is listening on.

Before we move to a fix, can I please confirm the problem, which is

When Envoy is configured to redirect a request from HTTP to HTTPS it is appending a port number.

Is that correct?

[sudeeptoroy]

When Envoy is configured to redirect a request from HTTP to HTTPS it is appending a port number.

For standard ports 80 and 443, no. This is correct behaviour.
However for cases where envoy if bound to a different hostport lets say 8000 and 6443 for http and https traffic; redirect is appending a port number but wrong one. In this case, after the redirect we would expect port 6443 but what we receive is 8000.

[davecheney]

@sudeeptoroy I think the solution is to see if there is a way to prevent envoy adding any port to the redirect; ie http://foo.com -> https://foo.com shouldn't need a port.

[sudeeptoroy]

@davecheney envoy would not add ports until you program it that way.

essentially https://github.com/envoyproxy/envoy/blob/feb56a1f8ee2cf1ea2048e20b7ba05f8199355c6/api/envoy/api/v2/route/route.proto#L954
need to be programmed only for cases when envoy is serving non standard ports; ie http://foo.com:8000 -> https://foo.com:6443

previously I had submitted this fix #1331
let me know if i should submit it again.

[davecheney]

Thank you for explaining. I played around with the rewriting options in envoy and it looks inescapable that we'll have to record the host port that traffic is nat'd into envoy on. I don't think we can commit to doing this work before Contour 1.0, as it needs to be threaded through contour's config file, the listener visitor and the route visitor.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack