From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: Handling HTTP "Upgrade" requests Date: Wed, 25 Feb 2015 13:05:43 +0800 Organization: HFG Message-ID: <1424840743.14360.18.camel@Renee-desktop.suse> References: <87wq3aan0s.fsf@fsf.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1424840768 18041 80.91.229.3 (25 Feb 2015 05:06:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 05:06:08 +0000 (UTC) Cc: guile-devel@gnu.org To: David Thompson Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 25 06:06:01 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YQUAY-00031m-6I for guile-devel@m.gmane.org; Wed, 25 Feb 2015 06:05:58 +0100 Original-Received: from localhost ([::1]:52867 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQUAX-0005CY-B8 for guile-devel@m.gmane.org; Wed, 25 Feb 2015 00:05:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQUAU-0005Az-Gy for guile-devel@gnu.org; Wed, 25 Feb 2015 00:05:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQUAT-0002GK-FR for guile-devel@gnu.org; Wed, 25 Feb 2015 00:05:54 -0500 Original-Received: from mail-pd0-x234.google.com ([2607:f8b0:400e:c02::234]:42182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQUAP-0002Dl-RS; Wed, 25 Feb 2015 00:05:50 -0500 Original-Received: by pdbfp1 with SMTP id fp1so2156807pdb.9; Tue, 24 Feb 2015 21:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:content-type:mime-version:content-transfer-encoding; bh=/t4KyiRlblCci7iHMFW08IQ1mF+JTn4lz7V4ldn6das=; b=S8rT2oLCTCCIH8yakY7jRVMuG1ZSMpPk1SUhCFakhNSZf6spH1j9ZTeyNS28jC+Cqq HayfrSR/8C5Rk2XBUBHsfHXzIqoFR6E7hp/dAPid/kKayX5LnKKuW/VgmZGFtFqw80cx 4EoUokjMAHaKqNJ6lRlnFOtHIDDTm4XLHSDdr03cShVAz57KFayXT9pgc0DzoPRGvu33 k0hS6l0wT+JCSBAD8z0+M2Aj2qB/Z6LoJrG8YWom+9c22I1QsGjt5sjtQPKtTvvSURms 4avK60cjob06qhmhdReK2mcYK3wkY4lOfxZkyQpsDgejGqgUbwDEPgDYHH3mRcaegBoz oJLg== X-Received: by 10.68.237.2 with SMTP id uy2mr2406211pbc.72.1424840748074; Tue, 24 Feb 2015 21:05:48 -0800 (PST) Original-Received: from [147.2.147.174] ([203.192.156.9]) by mx.google.com with ESMTPSA id x4sm15880622pas.40.2015.02.24.21.05.45 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 24 Feb 2015 21:05:46 -0800 (PST) In-Reply-To: <87wq3aan0s.fsf@fsf.org> X-Mailer: Evolution 3.4.4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c02::234 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17677 Archived-At: 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 # #) > In web/server/http.scm: > 126:17 2 (#) > In web/request.scm: > 204:31 1 (read-request # ()) > In ice-9/boot-9.scm: > 106:20 0 (# ...) > 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 >