Description of problem: "unable to upgrade connection" occurs when run oc exec against oc proxy. Version-Release number of selected component (if applicable): oc v1.3.0-alpha.1-379-g662753c kubernetes v1.3.0-alpha.3-599-g2746284 How reproducible: Always Steps to Reproduce: 1. oc login, create project and resources $ oc login --server https://<master>:<port> $ oc new-project xxia-proj $ oc new-app -f origin/examples/sample-app/application-template-stibuild.json token=`oc whoami -t` 2. $ oc proxy --port=8011 Starting to serve on 127.0.0.1:8011 3 On another terminal, check oc exec against oc proxy $ oc get pod --server 127.0.0.1:8011 --token=$token -n xxia-proj $ oc exec <pod> --server 127.0.0.1:8011 --token=$token -n xxia-proj -- ls /ect/hosts Check other oc commands: $ oc new-app openshift/hello-openshift --name myapp --server 127.0.0.1:8011 --token=$token -n xxia-proj $ oc edit dc myapp --server 127.0.0.1:8011 --token=$token -n xxia-proj Actual results: 3. For oc exec, it outputs: error: unable to upgrade connection: <h3>Unauthorized</h3> For other oc commands, success. Expected results: 3. oc exec should succeed as other oc commands. Additional info:
`oc proxy` by default rejects certain paths and http methods: --reject-methods='POST,PUT,PATCH': Regular expression for HTTP methods that the proxy should reject. --reject-paths='^/api/.*/exec,^/api/.*/run,^/api/.*/attach': Regular expression for paths that the proxy should reject. If you were to start the proxy and allow those methods/paths (e.g. oc proxy --port=8011 --reject-paths "^MAKEITWORK$" --reject-methods="^MAKEITWORK$"), you'll find that it still doesn't work. This time, you get: $ oc --server 127.0.0.1:8011 exec nginx date Error from server: Upgrade request required This is because the proxy code is using the default reverse proxy built in to go, which is not upgrade aware.
Given that the default configuration is to block exec, attach, and run from working through the proxy, I'm going to lower the severity on this one.
In reply to comment 3: I believe the thread mentioned in comment 5 mentions the addition of the `--http-proxy` and `--https-proxy` flags to the `oc cluster up` command. Since those flags have been added to the command for some time now, are there any additional parts of this issue that are left unresolved? If I understand correctly, using the built-in go proxy will continue to fail whenever a connection attempts to be upgraded, but it should now work if a user specifies their own proxy and it supports upgrading connections.
Thanks for you concern. Sorry for late reply Checked, comment 6 is right. Latest v3.7 `oc proxy` has as same result as "Description". For user specified proxy, yeah it has supported upgrading connections for long time: $ export http_proxy=company_proxy:3128 $ export https_proxy=company_proxy:3128 $ oc exec mysql-1-bthdv -- ls /etc/hosts /etc/hosts Closing it to the status as before comment 3