Re: [libmicrohttpd] Tiny request

[Junker, Gregory]

Hi Christian

I wouldn't characterize it as an Intel request -- the need is for a partner I 
am working with, but they are skittish about making changes to open source 
software so I registered for the list with my Intel email (as Intel is not 
nearly as leery, in case I needed to make and submit changes). 

We can take further discussions offline if you like, to talk about design 
issues (for instance, I had completely forgot about HTTPS support as well, as 
you mention in the issue linked below). I have some cycles available so it 
would be interesting to see the amount of work necessary to do it right. I have 
a decent feel for the codebase so it's not as if I would be starting cold (and 
it wouldn't be the first WS server I've implemented in C).

Thanks
Greg 

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Christian Grothoff
Sent: Wednesday, December 3, 2014 5:01 PM
To: address@hidden
Subject: Re: [libmicrohttpd] Tiny request

Dear Greg,

Yes, full support for WebSockets is more complex and an open feature request 
for a while (https://gnunet.org/bugs/view.php?id=2102). I would like to do this 
"right", but other things are keeping me busy.

I thought your patch's goal was merely to enable a slightly more "compliant" 
failure situtation for WebSocket clients.  If Intel has a strong need for 
'real' WebSocket support in MHD, we should discuss this off-list, as this not a 
'tiny request' anymore ;-).


Happy hacking!

Christian

On 12/04/2014 01:39 AM, Junker, Gregory wrote:
> 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
>> 
> 
>