Hi David! IMHO, there's no HTTP header anymore once you've done handshake successfully, but sending frame defined by WebSocket.
For this case, once handshake is successful, I think you have to spawn a new server instance (or use callbacks, depends on your server architecture design) rather than using Guile inner HTTP server to manage this socket. Or it'll be cracked while parsing HTTP header as you pasted. One of the possible way is to build a WebSocket gateway to dispatch the connections to each server instance (or callbacks) and managing handshake for each connection. Anyway, to support WebSocket, one have to customize the server core. The Guile inner server is dedicated to be the HTTP one, IIRC. That's why I stopped development of websocket module in Artanis, since I have to write its new async server core first. ;-) On Sat, 2015-02-21 at 18:00 -0500, David Thompson wrote: > I've been tinkering with adding WebSockets[0] support to Guile's HTTP > arsenal. The first blocking issue I've come across is that an HTTP > server must be able to detect the "Upgrade" header[1] and change > protocols. In my case, once a client thread accepts a WebSocket > connection, it should speak the WebSocket protocol, not HTTP. > > Here's an example of a backtrace that you'd see after a successful > WebSocket handshake, when the client tries to actually make use of the > socket: > > In ice-9/boot-9.scm: > 171:12 3 (with-throw-handler #t #<procedure 1720560 at web/...> #) > In web/server/http.scm: > 126:17 2 (#<procedure 1720560 at web/server/http.scm:125:15 ()>) > In web/request.scm: > 204:31 1 (read-request #<closed: file 0> ()) > In ice-9/boot-9.scm: > 106:20 0 (#<procedure 10ce380 at ice-9/boot-9.scm:97:6 (thr...> ...) > ERROR: Bad request: Bad Request-Line: "\x81\x86B\x93�Q" > > Does anyone have an idea about how to approach this problem? > > Thanks in advance! > > [0] http://www.websocket.org/ > [1] http://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header >