From: Nala Ginrut <nalaginrut@gmail.com>
To: David Thompson <davet@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: Handling HTTP "Upgrade" requests
Date: Wed, 25 Feb 2015 13:05:43 +0800 [thread overview]
Message-ID: <1424840743.14360.18.camel@Renee-desktop.suse> (raw)
In-Reply-To: <87wq3aan0s.fsf@fsf.org>
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
>
next prev parent reply other threads:[~2015-02-25 5:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-21 23:00 Handling HTTP "Upgrade" requests David Thompson
2015-02-25 5:05 ` Nala Ginrut [this message]
2015-02-25 16:23 ` Dave Thompson
2015-02-26 7:51 ` Nala Ginrut
2015-03-10 20:59 ` Andy Wingo
2015-03-11 3:55 ` Nala Ginrut
2015-03-04 10:51 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1424840743.14360.18.camel@Renee-desktop.suse \
--to=nalaginrut@gmail.com \
--cc=davet@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).