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: Thu, 26 Feb 2015 15:51:40 +0800 Organization: HFG Message-ID: <1424937100.7013.37.camel@Renee-desktop.suse> References: <87wq3aan0s.fsf@fsf.org> <1424840743.14360.18.camel@Renee-desktop.suse> <8dvbiqufhr.fsf@freestation00.office.fsf.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1424937137 20031 80.91.229.3 (26 Feb 2015 07:52:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Feb 2015 07:52:17 +0000 (UTC) Cc: guile-devel@gnu.org, David Thompson To: Dave Thompson Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Feb 26 08:52:03 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 1YQtEo-00036N-KB for guile-devel@m.gmane.org; Thu, 26 Feb 2015 08:52:02 +0100 Original-Received: from localhost ([::1]:57754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQtEn-0005ms-L7 for guile-devel@m.gmane.org; Thu, 26 Feb 2015 02:52:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQtEg-0005hb-Ot for guile-devel@gnu.org; Thu, 26 Feb 2015 02:51:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQtEf-00079N-PY for guile-devel@gnu.org; Thu, 26 Feb 2015 02:51:54 -0500 Original-Received: from mail-pd0-x236.google.com ([2607:f8b0:400e:c02::236]:34377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQtEa-00078R-TQ; Thu, 26 Feb 2015 02:51:49 -0500 Original-Received: by pdjg10 with SMTP id g10so11239904pdj.1; Wed, 25 Feb 2015 23:51:47 -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=i+0mF2jcgnX8VxtX2ob3ewP05QgHwkP1zc593Mr18S4=; b=cjsQb9O+D5Sfawj/Ea4rUfNDPir9pKD2rZ/iO0YMlpVDKDV9sq8otCldyJv8rCOAEq HLJ0TqCYyh16QxDvBZmet7R+34OiZMIxBOG8u1pAew0PNkIrYjnmbdyt6ob4eZgfl4pR W0vmgdTI+7SsGke9oDxfiyEO9+I8hDh+N00/sSJVxJYhTzDPy6C6rk6nMnIukv+Zv2O/ ZLEA5hEw9jdmG04bqChitLzi3hUoMTL09e6JR9FQ8BPqyS43C2WJHhe1rLIr7hgY8zkr YS7rH49NGdmTNIUT9Dd4wK+OoJKp/sCwyNkWIZpQqwKrzHHw8bQDfRIggGBn/pAywNPF vmvA== X-Received: by 10.66.141.42 with SMTP id rl10mr12664395pab.124.1424937107381; Wed, 25 Feb 2015 23:51:47 -0800 (PST) Original-Received: from [147.2.147.174] ([203.192.156.9]) by mx.google.com with ESMTPSA id z2sm35219708pde.94.2015.02.25.23.51.43 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 25 Feb 2015 23:51:44 -0800 (PST) In-Reply-To: <8dvbiqufhr.fsf@freestation00.office.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::236 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:17679 Archived-At: On Wed, 2015-02-25 at 11:23 -0500, Dave Thompson wrote: > 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. > Ah I see. > 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. Personally, I don't think websocket part should be based on inner HTTP server. Or there'd be some changes of the architecture. But if you really want to use inner server, I think there're some points to be noticed: 1. check if it's websocket frame, then call the registered handler and skip read-request to avoid the problem you've pasted; 2. the current inner server detects keep-alive based on HTTP header, so you have to modify something to support comet connection for websocket ports. 3. I have to mention that the current inner server is not non-block and weak for slow-header-DDOS. So if you handle one request in a long time, others' requests will be blocked in a long time. One of the easy solution is to take advantage of Nginx reverse-proxy. But it doesn't solve all the issues. ;-P PS: To those who care, unfortunately, Guile has no epoll/kqueue yet, that's one of the reasons why I want to write new server core for Artanis. ;-) Happy hacking!