Envoy: Better handling for domain matching with ports

[robertfreund]

When explicitly adding port 80 to host such as http://host:80 it will not allow a redirect to https://host:443.

require_ssl of the virtualHost will redirect to https://host:80. What is desired is a redirect to https://host:443 when :80 is explicit.

[mattklein123]

I'm not completely clear on the right behaviors here per RFCs. Needs some research. This would be a good opportunity to generally look at how we handle port inside the host/authority header.

[wangjunwei87]

example.com:443 and example.com should be the same virtual host, but currently, gRPC requests with port in authority got 404.

It will be great if envoy strip the standard port portion(like 443, or 80), then do domain match to decide which virtual host a request should go.

[swift1911]

any progress this issue?

[jeteon]

A workaround that seems to work is to explicitly match on both a version with and without the port.

This was quite surprising to find. In my case I struggled to see why Prometheus scrape requests failed with 404s when browser (and almost everything else) checks on the same URL worked just fine. It was only when I discovered that it added the port to the domain that I found this issue.

[bitsofinfo]

Anyone have a workaround for Envoy based gateways configurable via kubernetes Ingress configs which gives the following if you try to qualify w/ port which is not permitted?

The Ingress "my-ingress" is invalid: spec.rules[0].host: Invalid value: "my-app.local:30443": a DNS-1123 subdomain must consist o
f lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a
-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

[An0nymous0]

Has this thing progressed?

[zuercher]

@bitsofinfo if the envoy virtual host were configured with domains: [ "host", "host:*" ] it will allow any port, including a port that was elided as the default port for the scheme.

[mamunozgonzalez]

Is there any progress on this? I'm also facing the issue (ended up here from https://github.com/istio/istio/issues/8807)

[gnz00]

From the feedback I received, I need to revisit the implementation to
create a map of well known protocols to their common port, and only attempt
to resolve those.

I haven’t had any time lately to revisit this and for my real world
implementation, I’ve just added a wildcard match for the port to my
VirtualHost configurations that are propagated via my control plane.

As this is totally resolvable via configuration/control-plane conventions,
I am hesitant to pick this back up. In my opinion, a “domain” should match
the IEEE definition from the RFC or the config property should be renamed
to “authorities” and then control-planes and end-users will be responsible
for enumerating the ports (or matching by wildcard).

On Tue, Sep 10, 2019 at 1:11 PM Miguel Angel Muñoz González <
[email protected]> wrote:

Is there any progress on this? I'm also facing the issue (ended up here
from istio/istio#8807 https://github.com/istio/istio/issues/8807)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/issues/886?email_source=notifications&email_token=AAW6VM6GQDHIENBFMSTRP3LQI7IK5A5CNFSM4DJ6QHQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6L2SYY#issuecomment-530032995,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAW6VM6GSXJRTXTDLWH6D53QI7IK5ANCNFSM4DJ6QHQA
.

[greenenergy]

I too am having issues with this, but I have another bit of info to add. I'm using istio, and trying to create Virtual Service & Gateway entries for both http and https services. The https service I have does its own TLS termination, so I'm using a TLS PASSTHROUGH. The istioingressgateway listens on port 31380 for http and 31390 for https. I am using happy.localdomain for the TLS service that works, and sad.localdomain for the http service that does not.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: happy-gw
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
    hosts:
    - happy.localdomain

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: happy-vs
spec:
  hosts:
  - happy.localdomain
  gateways:
  - happy-gw
  tls:
  - match:
    - port: 443
      sni_hosts:
      - happy.localdomain
    route:
    - destination:
        host: happy-svc
        port:
          number: 8443

This works perfectly. Requests going to https://happy.localdomain:31390 get sent correctly to port 8443 of happy-svc.

But this does not work:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: sad-gw
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "sad.localdomain"

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sad-vs
spec:
  hosts:
  - "sad.localdomain"
  gateways:
  - sad-gw
  http:
    - destination:
        port:
          number: 8080
        host: sad-svc

Requests to http://sad.localdomain:31380 return 404.

$ curl -vvv http://sad.localdomain:31380
* Rebuilt URL to: http://sad.localdomain:31380/
*   Trying 192.168.99.100...
* Connected to sad.localdomain (192.168.99.100) port 31380 (#0)
> GET / HTTP/1.1
> Host: sad.localdomain:31380
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< date: Wed, 23 Oct 2019 22:15:43 GMT
< server: istio-envoy
< content-length: 0
< 
* Connection #0 to host sad.localdomain left intact

Why does it work for TLS connections but not HTTP?