libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] upgrading and life cycle of sockets


From: José Bollo
Subject: Re: [libmicrohttpd] upgrading and life cycle of sockets
Date: Tue, 24 Nov 2020 15:48:20 +0100

On Tue, 24 Nov 2020 15:34:03 +0100
Christian Grothoff <grothoff@gnunet.org> wrote:

> Hi Jose,
> 
> Well, technically you can dup() around this and call action close
> early. HOWEVER, this breaks BADLY if you ever use TLS connections:
> here, MHD will right now ensure that you write plaintext into your
> socket and turn it into ciphertext for the network. That's why MHD
> needs to keep some state per connection, and if you break that, well,
> kiss TLS-support goodbye.
> 
> So I would not recommend for applications to try to take any 'full
> control' of the socket, simply because it may not be the real socket
> and merely be a socketpair to talk to MHD's TLS-adapter ;-).

Hi Christian,

You are confirming what I knew. But there is still something that I
don't understand. Let me use a diagram to show what I understand

 CLIENT <----- TLS -----> MHD  <---- socket pair -----> MY PROGRAM

If that diagram is correct MHD has only to deal with 2 items: the TLS
socket and one of the socket pair. If the program close its pair, it is
detect and is handled correctly with only one of the 2 items created by
socketpair.

Can you explain me more what I'm missing?


> Happy hacking!
> 
> Christian
> 
> On 11/24/20 3:23 PM, José Bollo wrote:
> > Hi there,
> > 
> > After a switching protocol for web socket for example, libmicrohttp
> > keeps the socket under the table until a call to MHD_upgrade_action
> > (something, MHD_UPGRADE_ACTION_CLOSE).
> > 
> > So, it enforces to have a link to libmicrohttp when using such
> > switched protocol socket.
> > 
> > Is it possible to break that link? To tell libmicrohttp to forget
> > and clean things related to that socket and let far part of code
> > use the socket freely?
> > 
> > Best
> > José
> >   
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]