vnc: 0.970
socket: 0.959
debug: 0.934
performance: 0.839
network: 0.826
ppc: 0.797
VMM: 0.765
device: 0.760
graphic: 0.752
user-level: 0.742
semantic: 0.732
kernel: 0.729
register: 0.717
risc-v: 0.716
KVM: 0.673
hypervisor: 0.660
arm: 0.643
PID: 0.608
architecture: 0.603
permissions: 0.596
i386: 0.595
x86: 0.573
files: 0.572
TCG: 0.540
boot: 0.537
peripherals: 0.524
virtual: 0.465
assembly: 0.398
mistranslation: 0.376

websockets: Improve error messages 

Since 2.9 / 07e95cd529af345fdeea230913f68eff5b925bb6 , whenever the VNC websocket server finds an error with the incoming connection request, it just closes the socket with no further information.

This makes figuring out what's wrong with the request nearly impossible.

I would be nice if:

* HTTP 400 were returned to the client, with an appropriate error message
* Maybe something written to the log as well?

Currently, I'm resorting to looking at my request and the websocket source and hoping I can figure out what's wrong.

At very least we should also use 404 if given a invalid path

Will be included  for 2.11 in 

commit 3a3f8705962c8c8a47a9b981ffd5aab7274ad508
Author: Daniel P. Berrange <email address hidden>
Date:   Wed Sep 6 11:38:36 2017 +0100

    io: include full error message in websocket handshake trace
    
    When the websocket handshake fails it is useful to log the real
    error message via the trace points for debugging purposes.
    
    Fixes bug: #1715186
    
    Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
    Signed-off-by: Daniel P. Berrange <email address hidden>

commit f69a8bde29354493ff8aea64cc9cb3b531d16337
Author: Daniel P. Berrange <email address hidden>
Date:   Wed Sep 6 11:33:17 2017 +0100

    io: send proper HTTP response for websocket errors
    
    When any error occurs while processing the websockets handshake,
    QEMU just terminates the connection abruptly. This is in violation
    of the HTTP specs and does not help the client understand what they
    did wrong. This is particularly bad when the client gives the wrong
    path, as a "404 Not Found" would be very helpful.
    
    Refactor the handshake code so that it always sends a response to
    the client unless there was an I/O error.
    
    Fixes bug: #1715186
    
    Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
    Signed-off-by: Daniel P. Berrange <email address hidden>