Strange router behavior for passthrough routes

[miminar]

Me and one customer find it very strange that router returns 503 HTTP code when the target service listens on :443 while the client tries to talk to :80. We would expect the router to redirect the client to a
secured :443 port.

The same situation applies to a service listening on :80 and client connecting to the router on :443 port.

Is there a reason for doing this? Could this be improved?

[miminar]

FYI @erikbsap

[erikbsap]

Thanks for creating the ticket @miminar.

My expectation would be something like this example with the non-redhat-docker-registry:

$ curl -k -vv localhost:5000/v2
* About to connect() to localhost port 5000 (#0)
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET /v2 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Docker-Distribution-Api-Version: registry/2.0
< Location: /v2/
< Date: Tue, 26 Sep 2017 09:28:07 GMT
< Content-Length: 39
< Content-Type: text/html; charset=utf-8
<
<a href="/v2/">Moved Permanently</a>.

With that info I as the user know that I have to do something different. But currently the Redhat docker registry will return HTTP 503, which gives the impression the cluster is unhealthy.

Also please note that the response in my example contains a header line which says I'm actually talking to the registry. This is already important information when debugging, because it means the name was resolved correctly and openshift could forward my request to the correct pod.

I don't know if HTTP 301is the right response type here. Google for instance uses JS to redirect to https, I believe. The how is not important though. The more important part is that the user has some way of knowing that he is expected to move on to port :443.

[Miciah]

Use oc create route passthrough --insecure-policy=Redirect or this equivalent stanza in the route definition:

spec:
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: passthrough

Using this, HTTP requests will get a 302 redirect to the HTTPS URL. For the reverse (HTTPS connections to an HTTP service), you could create a second, edge route. Does that work for your use case?

[erikbsap]

Yes, nice! This way it's also part of a policy and it makes sense that it isn't done as default. Is there a way to configure that in the hosts file for openshift advanced installation?

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close