modify automake to include ws_decode test
add python frame generator for decode tests
modify configure to only include ws_decode test if preconditions are
fulfilled
fix critical heap-based buffer overflow which allowed easy modification
of a return address via an overwritten function pointer
fix bug causing connections to fail due a "one websocket frame = one
ws_read" assumption, which failed with LibVNCServer-0.9.11
refactor websocket Hybi decode to use a simple state machine for
decoding of websocket frames
- When processing input, check if there is any extra data
pending in the internal websocket frame and SSL buffers.
- Prevents input events lagging behind because they get
stuck in one of the buffers.
Data pending in our own buffers cannot be detected with
select() so was not processed until more input arrives
from the network.
- Closes # 55
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
GCC < 4.6 failed to parse the declaration of ws_header_t correctly because
it did not accept anonymous structs and unions. [1]
Work around the bug by adding names to the unions and structs. Ugly, but
works.
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4784
byteswap.h exists only on glibc, so building libvncserver with websockets
support was not possible in other systems.
Replace the inclusion of byteswap.h and the WS_* definitions with calls to
htobeNN, which should perform the same conversions, be more portable and
avoid the need to check for the platform's endianness.
The current definitions were mostly useful to glibc and followed its
feature_test_macros(3) documentation.
However, this means other platforms still had problems when building with
strict compilation flags. _BSD_SOURCE, for example, is only recognized by
glibc, and other platforms sometimes need _XOPEN_SOURCE instead, or even the
removal of some definitions (such as the outdate _POSIX_SOURCE one).
_POSIX_SOURCE also had to be conditionally defined in some places, as what
it enables or disables during compilation varies across systems.
Building with -ansi failed due to some code (as well as system
headers) using non-C89 features. Fix that by adding the usual
_POSIX_SOURCE and _BSD_SOURCE definitions already present in some
other files.
Add common/sha1.h and common/sha1.c so that we have the SHA routines
even if openssl is not available. From the IETF SHA RFC example code.
Remove the UTF-8 encoding hack. This was really just an experiment.
If the protocol passed in the handshake has "binary" then don't base64
encode for the HyBi protocol. This will allow noVNC to request the
binary data be passed raw and not base64 encoded. Unfortunately, the
client doesn't speak first in VNC protocol (bad original design). If
it did then we could determine whether to base64 encode or not based
on the first HyBi frame from the client and whether the binary bit is
set or not. Oh well.
Misc Cleanup:
- Always free response and buf in handshake routine.
- Remove some unused variables.
Move the hixie disconnect hack to websockets.c. Removed
the remaining websockets vars from rfbClientPtr, so all
websockets stuff is hidden behind an opaque pointer.
Added wspath member to rfbClientRec which holds the
path component of the initial websocket request.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
[jes: moved out GnuTLS and OpenSSL support, added a dummy support, to
separate changes better, and to keep things compiling]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is not completely standard UTF-8 encoding. Only code points 0-255
are encoded and never encoded to more than two octets. Since '\x00' is
a WebSockets framing character, it's easier for all parties to encode
zero as '\xc4\x80', i.e. 194+128, i.e. UTF-8 256.
This means that a random stream will be slightly more than 50% larger
using this encoding scheme. But it's easy CPU-wise for client and
server to decode/encode. This is especially important for clients
written in languages that have weak bitops, like Javascript (i.e. the
noVNC client).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Has a bug: WebSocket client disconnects are not detected.
rfbSendFramebufferUpdate is doing a MSG_PEEK recv to determine if
enough data is available which prevents a disconnect from being
detected.
Otherwise it's working pretty well.
[jes: moved added struct members to the end for binary compatibility with
previous LibVNCServer versions, removed an unused variable]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Andreas Weigel
Christian Beier
Christian Beier
Kyle Russell
plettix
Floris Bos
Daniel Cohen Gindi
Joel Martin
Raphael Kubo da Costa
Gernot Tenchio
Gernot Tenchio
Joel Martin