1 files changed, 82 insertions, 0 deletions
diff --git a/results/classifier/118/vnc/1715186 b/results/classifier/118/vnc/1715186
new file mode 100644
index 000000000..4e6e134ad
--- /dev/null
+++ b/results/classifier/118/vnc/1715186
@@ -0,0 +1,82 @@
+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>
+
+