On Wed, Mar 12, 2014 at 2:30 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > On Wed, Mar 12, 2014 at 02:18:04PM +0100, Marc-André Lureau wrote: >> On Wed, Mar 12, 2014 at 2:15 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: >> > On Tue, Mar 11, 2014 at 07:12:56PM +0100, Marc-André Lureau wrote: >> >> On Tue, Mar 11, 2014 at 6:03 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: >> >> > When qemu only accepts TLS connections, but spice-gtk is given an URI with >> >> > both port and tls-port specified, spice_session_channel_open_host() is >> >> > first attempted to the non-TLS port, and when that fails, >> >> > spice_channel_coroutine() retries a TLS connection. >> >> > >> >> >> >> On a second thought, I think it was also a good idea to report an >> >> error when the specified non-tls port is invalid. >> > >> > I did not get what you want here :-/ In which situation exactly do you want >> > an error to be reported? >> >> When the given plain port doesn't exist or G_IO_ERROR_CONNECTION_REFUSED. >> >> That is, it is a good thing to report an error if the spice server >> only accepts tls connection, but the client was given a plain port >> too. >> >> No? > > You can probably hit this situation too when the server listens on both > TLS/non-TLS ports and use 'tls-channel' to force some of the channels to > use TLS. If the server is listening on this port, it will not report an error here. > Regardless of that, refusing to connect when the client got passed TLS and > non-TLS port if the server is not listening on a non-TLS port is a change > of behaviour with earlier versions. And I would not be surprised this > change of behaviour would break some existing setups. I am not convince this was desirable, so changing behaviour would be a fix for me: reporting an error for an unexisting port is useful. -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel