Roasting old chestnuts

Robert de Bath
Sun Jul 6 14:26:01 2003

Please don't run away, I do seem to have a new slant on this can of wormy

The label on the can is "file transfers".

What I propose is that the file transfer that _already_exists_ in VNC is
used. This means there would be NO CHANGES NEEDED to any PROTOCOL.

Just use the http server on port 5800+

You see many people don't realise that bare http is a bi-directional
protocol; everybody knows of the http GET command but there is also
a http PUT command that's used to send a file to the server.

Details, Server end.

The server on port 5800+ would be extended to allow http file transfers
both to and from a specific directory. On the windows server the directory
should be accessable from the systray icon. On all servers it should be
a user specified directory with a disable.

Details, Client end.

File transfer _could_ be integrated into the normal client but this
isn't required. A separate file transfer client could just as easily
be invoked from a command menu, it's job would be to:

1) GET and display a file with the current directory list.
     The file could be _very_ simple html, eg an Apache directory list.
2) GET any file on that list and store it locally.
3) PUT a local file onto the server into that list.

All using dumb http to port 5800+
The invocation from the VNC client would just be:
  http-xfer http://servername:portno/fixedpath/
or when/if https is added.
  http-xfer https://servername:portno/fixedpath/

Details, Authentication.

Some form of authentication is _required_, you really don't want any
old AFLWer sending you files.

Basic http authentication would do the trick, but it would need the
user to re-enter their password, and the password is sent repeatedly
in plaintext.

A better method would be to get a 'security cookie' from the server
this could be a HTTP cookie or something else. It would be really
nice if this cookie was requested from the server via the RFB
connection so the user doesn't have to re-enter their password,
but that would involve a change to the RFB protocol.
The cookie should timeout eventually so basic auth would still be


With a little bit of scripting MSIE can do http put commands but it's
very bad at it (no resume, no progress indication) so a dedicated
client would be _much_ better. There are some very good command line
utilities for this (eg: ), however I haven't
yet found a nice Win32 GUI one.

People using ssh, zebedee or firewalls would need to add the 5800+
port to their tunnels in addition to the 5900+ port. All connections
are initiated from the client end which makes it easy, unlike ftp.

Assuming a dedicated Win32 transfer client is written it should use
completely standard protocols so it can interect with (eg) Apache's
put,get and directory index. Also I would imagine there are lots of
useful features it could be given; jobs queues, bandwidth limiting,
DELETE command, HTTP server, etc etc. But as it's a separate client
that's not VNC bloat is it :)

Finally: Yes I've heard of ultravnc, but it's windows only.

Rob.                          (Robert de Bath <robert$ @>)
Google Homepage: