From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Thompson Newsgroups: gmane.lisp.guile.devel Subject: Re: Handling HTTP "Upgrade" requests Date: Wed, 25 Feb 2015 11:23:44 -0500 Message-ID: <8dvbiqufhr.fsf@freestation00.office.fsf.org> References: <87wq3aan0s.fsf@fsf.org> <1424840743.14360.18.camel@Renee-desktop.suse> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424890060 9292 80.91.229.3 (25 Feb 2015 18:47:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 18:47:40 +0000 (UTC) Cc: guile-devel@gnu.org To: Nala Ginrut , David Thompson Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Feb 25 19:47:33 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 1YQgzc-0007zf-LO for guile-devel@m.gmane.org; Wed, 25 Feb 2015 19:47:32 +0100 Original-Received: from localhost ([::1]:55930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQgzb-0007ch-KY for guile-devel@m.gmane.org; Wed, 25 Feb 2015 13:47:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQeh4-0005ei-Lx for guile-devel@gnu.org; Wed, 25 Feb 2015 11:20:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQeh3-0004kM-KL for guile-devel@gnu.org; Wed, 25 Feb 2015 11:20:14 -0500 Original-Received: from mail.fsf.org ([208.118.235.13]:57974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQeh3-0004kF-HE; Wed, 25 Feb 2015 11:20:13 -0500 Original-Received: (helo=freestation00.office.fsf.org) by mail.fsf.org with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1YQeh0-0006Tg-BP; Wed, 25 Feb 2015 11:20:12 -0500 In-Reply-To: <1424840743.14360.18.camel@Renee-desktop.suse> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) X-detected-operating-system: by mail.fsf.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.13 X-Mailman-Approved-At: Wed, 25 Feb 2015 13:47:29 -0500 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:17678 Archived-At: Nala Ginrut writes: > Hi David! > > IMHO, there's no HTTP header anymore once you've done handshake > successfully, but sending frame defined by WebSocket. Yes, that is true. > 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. ;-) IMO, an asynchronous/multi-threaded server is a separate issue. I was aiming for a solution that allowed a single websocket to be used on Guile's single-thread default web server. Of course, the websocket implementation should be able to be applied to a more advanced server, should one be written. I think you're right that something in the default HTTP server must be changed, but I haven't grokked the implementation enough to figure it out. AFAICT, the HTTP server socket needs to be handed over to a WebSocket server procedure, suspending additional HTTP request processing until the WebSocket is closed and the socket is handed back to the HTTP server. Does that make some sense? Things are too foggy for me to tell. -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate