[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] Tiny request
From: |
Junker, Gregory |
Subject: |
Re: [libmicrohttpd] Tiny request |
Date: |
Thu, 4 Dec 2014 00:39:18 +0000 |
Thanks Christian
Unfortunately, I realized that is not actually enough. WebSocket uses the
existing TCP connection with the webserver for further WebSocket-framed
traffic. This requires that MHD "orphan" the MHD_Connection it originally set
up for the incoming request (and release the existing socket descriptor to
ownership and control of user code). I've been looking through the source in
daemon.c and it looks like a fairly complex (various combinations of
polling/not-polling/selecting/thread-or-not-thread-per-connection, and so on).
Am I just overreading the amount of work, or is it actually non-trivial to pull
this off?
Thanks again!
Greg
-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Christian Grothoff
Sent: Wednesday, December 3, 2014 3:47 PM
To: address@hidden
Subject: Re: [libmicrohttpd] Tiny request
Done (SVN 34474). -Christian
On 12/04/2014 12:30 AM, Junker, Gregory wrote:
> Hi all
>
> I need a tiny addition made to connection.c.
>
> In keepalive_possible(), can we change the line that says
>
> if (0 == strcasecmp (end, "close"))
>
> to
>
>
>
> if (0 == strcasecmp (end, "close") || 0 == strcasecmp (end, "upgrade"))
>
> ?
>
> This would make it possible to use libmicrohttpd in a WebSocket (RFC6455)
> environment. Currently, the way that the WebSocket protocol works, it sends
> "Connection: Upgrade" in the headers with the initial handshake, which causes
> this check to fail and (ultimately) insert "Connection: Keep-Alive" in the
> response headers (which cause any compliant WebSocket client to fail the
> handshake, since it needs "Connection: Upgrade" in the response headers, and
> there is no way to remove this keepalive header from the response from
> outside of MHD, as it is added automatically to the response buffer).
>
> Note that this is only an HTTP/1.1 issue, AFAIK (I am pretty sure, though not
> positive, that WebSocket is not compatible with HTTP/1.0).
>
> Thanks!
> Greg
>