necouchman commented on a change in pull request #219: GUACAMOLE-422: Add
timezone to client handshake
URL: https://github.com/apache/guacamole-server/pull/219#discussion_r276385194
##########
File path: src/protocols/kubernetes/settings.c
##########
@@ -25,6 +25,14 @@
/* Client plugin arguments */
const char* GUAC_KUBERNETES_CLIENT_ARGS[] = {
+ /**
+ * This first argument defines the protocol version in use so that the
+ * client knows how to handle talking to different versions of guacd.
+ * If this is omitted the client may choose not to enable certain
+ * features.
+ */
+ "VERSION_1_1_0",
Review comment:
Okay, so I've played around with this a bit more and got it to the point
where it works across various combinations of server and client versions in a
consistent and expected way. As it is right now, I ended up just removing the
first argument on the guacd side. The client implementation does not currently
populate a value for the protocol version, it simply examines the protocol that
the server sends and adjusts accordingly (see apache/guacamole-client#348).
The various scenarios are:
* Server 1.1.0, Client 1.1.0: Server sends protocol version and args to
client, client examines and sets protocol version, adjusts handshake, and sends
back an empty value for the protocol version argument. The server then ignores
this argument when joining the user to the connection by decrementing `argc`
and passing through `argv + 1` to the join function.
* Server 1.1.0, Client 1.0.0 (or lower): Server sends protocol version and
args to client, client has no knowledge of protocol version, so does not adjust
handshake at all, and sends back an empty value for the protocol version
argument. The server ignores/strips the argument when joining using the same
method as above.
* Server 1.0.0 (or lower), Client 1.1.0: Server sends arguments to client,
without any protocol version. The client checks for protocol version and does
not see it, so it does not add any of the additional protocol-related
functionality and simple passes through the supported handshake and arguments.
The server processes all of the arguments as usual.
So, my two questions would be:
* Is there some use-case I'm missing here where checking the number of
provided/expected arguments in the handshake actually helps anything out? As
it is, it seems to work with various combinations of the server and client, so
I'm not sure this is valuable?
* I currently have the client where it simply sends an empty argument back
for the protocol version - is there any reason to have it populate something
else in that argument, like the actual protocol version it's using? It doesn't
seem to need it right now in order to function properly, but maybe it's worth
just implementing it this way, anyway, to future-proof it? Or just leave it
as-is?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
