+++ This bug was initially created as a clone of Bug #1446360 +++ Description of problem: If a Route object specifies a path ending in a /, subpaths are not routed correctly Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a route with a path of / routing to a pod 2. Access the route's hostname at the following URLs: https://<host> https://<host>/ https://<host>/test Actual results: The root paths work. The /test subpath fails to route Expected results: All three paths route correctly. Additional info: --- Additional comment from Jordan Liggitt on 2017-04-27 14:01:46 EDT --- Fixed upstream in master in https://github.com/openshift/origin/pull/13867 Fixed upstream in 1.5 in https://github.com/openshift/origin/pull/13923 Fixed in 3.5 in https://github.com/openshift/ose/pull/726 Testcase: Create three routes using the same host, routing to different pods (so you can identify which route served which request) Route 1: path of / Route 2: path of /subpath Route 3: path of /subpath/ Ensure the following urls are served by the expected routes: route 1: https://<host> https://<host>/ https://<host>/test route 2: https://<host>/subpath route 3: https://<host>/subpath/ https://<host>/subpath/subsubpath --- Additional comment from Meng Bo on 2017-04-27 21:48:35 EDT --- What if an user wants to allow to access the http(s)://<host>/ only but none of the subpath? --- Additional comment from Jordan Liggitt on 2017-04-27 21:59:05 EDT --- That is not an option today
This is to track the fix that went in for 3.6.
verified this bug on v3.6.86 oc get route service-unsecure NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD service-unsecure service-unsecure-default.0531-9ye.qe.rhcloud.com / service-unsecure http None $ curl service-unsecure-default.0531-9ye.qe.rhcloud.com Hello-OpenShift-1 http-8080 curl service-unsecure-default.0531-9ye.qe.rhcloud.com/path/second/ second-test http-8080 curl service-unsecure-default.0531-9ye.qe.rhcloud.com/path/ ocp-test http-8080
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/RHEA-2017:1716