Description of problem: When there exists secured wildcard route to a service, then all unsecured routes in same subdomain are overriden and forwarded to service behind wildcard route. Version-Release number of selected component (if applicable): ose-haproxy-router:v3.9.27-2 How reproducible: Steps to Reproduce: 1. Create wildcard route with Edge termination type pointing to one service (let's call it svcA) with hostname *.wildcard.example.com 2. Create unsecured route pointing different service (let's call it svcB) with hostname failing.wildcard.example.com Actual results: All requests to http://failing.wildcard.example.com will be directed to svcA Expected results: All requests to http://failing.wildcard.example.com should be directed to svcB Additional info: If the wildcard route is unsecured, then this problem is not manifesting.
hi, I just did the testing with version v3.9.27-2(id=b5626c63f5ad). but I cannot reproduce this issue: steps: 1. oc env dc router ROUTER_ALLOW_WILDCARD_ROUTES=true -n default 2. Create one appA pod/svc/edge route oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/wildcard_route/caddy-docker.json oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/edge/service_unsecure.json oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/wildcard_route/route_edge.json 3. Create another appB pod/svc/unsecure route $oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/header-test/dc.json $oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/header-test/insecure-service.json $oc expose svc header-test-insecure --hostname=test.edge.example.com 4. oc get route -n z1 NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD header-test-insecure test.edge.example.com header-test-insecure http None wildcard-edge-route wildcard.edge.example.com service-unsecure <all> edge Subdomain 5. access the wildcard edge route curl --resolve test.edge.example.com:443:172.30.46.174 https://test.edge.example.com -k Hello-OpenShift-1 http-8080 6. access the unsecure route. curl --resolve test.edge.example.com:80:172.30.46.174 http://test.edge.example.com <pre> user-agent: curl/7.29.0 accept: */* host: test.edge.example.com x-forwarded-host: test.edge.example.com x-forwarded-port: 80 x-forwarded-proto: http forwarded: for=172.16.120.87;host=test.edge.example.com;proto=http x-forwarded-for: 172.16.120.87 </pre>
Hello, please try to add this parameter to your wildcard route insecureEdgeTerminationPolicy: Allow That is the only difference between my setup and yours.
*** This bug has been marked as a duplicate of bug 1570143 ***
Reopening this after consulting with our team. This is not a duplicate but a more specific case which was not fixed by BZ#1570143. While BZ#1570143 fixed the issue for secured routes, for unsecured routes the problem persisted even after the fix. Can we please get this fixed and scheduled for some upcoming 3.9 erratum?
@ram: I've flagged this for 3.9.z, but can you check to see if it affects 3.10 please? We may need to mark this bug 3.11 and clone it for 3.10.z and 3.9.z. Thanks
@Ben, just checked - can confirm that is _not_ an issue with 3.10. There have been changes to the haproxy config template since 3.9 - especially to combine the map files (I think one of the reasons Jacob did that was to fix some issues with path based routing but it also simplified the approach). So this will have to be just a 3.9[.x] specific fix. Have to see what we can do there - we can't simply backport the change as the templates are a bit off. What's the eta (well really etd) on this?
Associated PR: https://github.com/openshift/ose/pull/1312 @Petr, if the customer wants this immediately, they can use a custom haproxy template with the changes from the PR. Instructions on how to use custom haproxy templates are at: https://docs.openshift.com/container-platform/3.9/install_config/router/customized_haproxy_router.html#using-configmap-replace-template
Check this on version (v3.9.31) found the haproxy image id( v3.9.31 58b5eed45aa6) has not merged the fixed PR 1312, So please help rebuild the haproxy image.
Verified this bug on oc v3.9.33 with haproxy image id(05f31c264207). see comment 1 and 2 for detail steps
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2213