Bug 1347647 - "unable to upgrade connection" occurs when run oc exec against oc proxy
Summary: "unable to upgrade connection" occurs when run oc exec against oc proxy
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OKD
Classification: Red Hat
Component: oc
Version: 3.x
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Fabiano Franz
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-17 10:24 UTC by Xingxing Xia
Modified: 2017-11-13 02:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-13 02:07:47 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Xingxing Xia 2016-06-17 10:24:59 UTC
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:

Comment 1 Andy Goldstein 2016-06-27 19:46:07 UTC
`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.

Comment 2 Andy Goldstein 2016-06-27 19:47:10 UTC
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.

Comment 6 Juan Vallejo 2017-10-03 20:59:07 UTC
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.

Comment 8 Xingxing Xia 2017-11-13 02:07:47 UTC
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


Note You need to log in before you can comment on or make changes to this bug.