Bug 1049475 - RHEVM sends to XPI SPICE plugin always SPICE proxy even one unchecks this options in Console Options
Summary: RHEVM sends to XPI SPICE plugin always SPICE proxy even one unchecks this opt...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-xpi
Version: 6.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: pre-dev-freeze
: ---
Assignee: Christophe Fergeau
QA Contact: SPICE QE bug list
Whiteboard: spice
Depends On:
TreeView+ depends on / blocked
Reported: 2014-01-07 15:32 UTC by Jiri Belka
Modified: 2015-07-22 07:28 UTC (History)
15 users (show)

Fixed In Version: spice-xpi-2.7-27.el6
Doc Type: Bug Fix
Doc Text:
* Previously, after enabling a proxy for a SPICE connection opened through the spice-xpi plug-in, the only way the user could unset the proxy was to close or reopen the web page. This update modifies spice-xpi to unset the SPICE_PROXY environment variable when the proxy is unset. As a result, unsetting a proxy for a SPICE connection works as expected. (BZ#1049475)
Clone Of:
Last Closed: 2015-07-22 07:28:18 UTC
Target Upstream Version:

Attachments (Terms of Use)
various logs... (340.56 KB, application/x-gzip)
2014-01-07 15:39 UTC, Jiri Belka
no flags Details
Unset SPICE_PROXY env var when proxy is not set (577 bytes, patch)
2015-03-16 17:02 UTC, Christophe Fergeau
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1393 normal SHIPPED_LIVE spice-xpi bug fix update 2015-07-20 18:07:32 UTC

Description Jiri Belka 2014-01-07 15:32:50 UTC
Description of problem:
RHEVM sends to XPI SPICE plugin always SPICE proxy even one unchecks this options in Console Options.

# engine-config -g SpiceProxyDefault
SpiceProxyDefault: version: general

$ sudo tcpdump -i eth0 -tttt -nn dst port 3128
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
2014-01-07 15:53:49.352756 IP > Flags [S], seq 1570298935, win 14600, options [mss 1460,sackOK,TS val 63395998 ecr 0,nop,wscale 7], length 0o

$ sudo sed -n '/Jan  7 15:53:45/,$p' /var/log/messages | grep -i proxy
Jan  7 15:53:45 localhost spice: SPICE_PROXY=
Jan  7 15:53:49 localhost spice: (remote-viewer:22936): GSpice-DEBUG: spice-session.c:1815 (with proxy
Jan  7 15:53:49 localhost spice: (remote-viewer:22936): GSpice-DEBUG: spice-session.c:1760 proxy lookup ready

$ sed -n '/2014-01-07 15:53:45,940/,$p' .spicec/spice-xpi.log | grep -i proxy
$ sed -n '/2014-01-07 15:53:45,940/,$p' .spicec/spice-xpi.log | grep -i 3128

In attachment there is: engine.log, spice-xpi.log, messages having DEBUG from spice xpi/remote-viewer and screenshots...

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. define spice proxy with engine-config and restart
2. VM - console options: plugin/uncheck spice proxy and open console

Actual results:
it tries to use proxy

Expected results:
should not use proxy

Additional info:

Comment 1 Jiri Belka 2014-01-07 15:39:41 UTC
Created attachment 846737 [details]
various logs...

Comment 2 Pavel Novotny 2014-01-07 16:08:06 UTC
I found the reproducer is a little bit trickier:
1. Launch browser and log into User Portal.
2. Open VM Console options, uncheck the SPICE proxy & save.
3. Open VM console -> VM console is opened this time!
4. Open VM Console options, check the SPICE proxy, save and try to open VM console again -> error "Unable to connect to the graphic server (null)".
5. Repeat steps 2 and 3. -> from this time the error is always returned.

Comment 3 Pavel Novotny 2014-01-07 16:17:09 UTC
In the very same way this bug affects also RHEVM 3.3 (rhevm-3.3.0-0.43.el6ev.noarch - is30).

Comment 4 Michal Skrivanek 2014-03-27 10:19:36 UTC
use case doesn't sound interesting enough for 3.5

moreover can't reproduce on dev setup yet

Comment 5 Michal Skrivanek 2014-08-14 13:52:27 UTC
care to re-try? we couldn't reproduce and I'm not aware of any complaints from teh field…would close otherwise

Comment 6 Jiri Belka 2014-08-15 08:36:45 UTC
I can still reproduce, proxy is not "reset" if it is unchecked in Console Options for browser plugin (xpi).


You should probably ask GSS who uses proxy and let them check.

Comment 7 Michal Skrivanek 2015-01-15 10:42:36 UTC
we didn't reproduce back then, nor now.
if you happen to reproduce please specify exact steps and make sure it reproduces on another setup too

Comment 8 Jiri Belka 2015-01-22 13:48:42 UTC
i can reproduce exactly as written in #2.


Comment 9 Tomas Jelinek 2015-03-16 13:05:00 UTC
OK, finally reproduced and it seems as an issue in spice-xpi.

Hi, it seems that when enabling the spice proxy in spice-xpi there is no way to disable it again - only restarting the browser.

It reproduces on:
all are the default versions on RHEL 6.6

please note it does not reproduce on Fedora 20 (spice-xpi-2.8.90-1.fc20.x86_64, virt-viewer-0.6.0-1.fc20.x86_64)

I was able to reproduce it both using oVirt and using the test page available here: https://teuf.fedorapeople.org/plugins/test.html
The steps for test page: 
- fill in the host/port
- connect
- it will work
- enable spice proxy and enter an incorrect value
- connect
- it will fail to connect since the proxy is not correct
- disable the spice proxy again and connect
- it will fail with the same error as when the proxy is enabled

after restarting the browser the spice proxy is disabled again and it is possible to connect again.

Is this a know issue? Since it seems to be fixed in more recent versions.

Comment 10 Christophe Fergeau 2015-03-16 17:02:27 UTC
Created attachment 1002406 [details]
Unset SPICE_PROXY env var when proxy is not set

This does not seem to be fixed upstream, but is working because upstream no longer looks at the SPICE_PROXY environment variable (?)
This patch fixes the issue for me (RHEL6 scratch build at https://brewweb.devel.redhat.com/taskinfo?taskID=8855582 ), I'll need to send a proper patch upstream

Comment 12 Tomas Jelinek 2015-03-17 10:27:32 UTC
I have tried the https://brewweb.devel.redhat.com/taskinfo?taskID=8855582  with my userportal and it works well - thanx!

Comment 17 errata-xmlrpc 2015-07-22 07:28:18 UTC
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.


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