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 16:50:49 +0100

On Tue, 24 Nov 2020 16:01:48 +0100
Christian Grothoff <grothoff@gnunet.org> wrote:

> On 11/24/20 3:48 PM, José Bollo wrote:
> > 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?
> >   
> 
> Relying on the application close()ing the socket could be problematic,
> as it may result in confusion for scenarios like half-closed sockets
> (and the client may also close or half-close).

That is what I missed, the complex case of half closing.

> OTOH, I can see that the current design is not great if your
> application expects to pass the socket to another process
> (fork/exec). (However, that use of the API is also a bit dangerous,
> as the client would end up with a very broken TLS connection if the
> parent with MHD exits -- while this would work fine for plaintext
> HTTP connections.)

It should be possible to handle such cases through programs.

> Is that your motivation, or what is the issue you're trying to solve
> here?

I have no real motivation. I changed part of my code and had to call
dup because other solutions were worst. Then I wanted to have a tiny
debate here just to fix my ideas on the subject.

I would be very happy to have the possibility to freely close the
socket in my program without having to know from where it comes. I
confirm that using dup does the job.

What about if in some future an option to MHD_upgrade_action would
enable to "extract" the socket? Something like:

        MHD_upgrade_action (urh, MHD_UPGRADE_ACTION_OWN_SOCKET);

with a clear semantic on the implications that it has on half-closing.



reply via email to

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