On Tue, 24 Nov 2020 16:01:48 +0100
Christian Grothoff <groth...@gnunet.org> wrote:
> On 11/24/20 3:48 PM, José Bollo wrote:
> > On Tue, 24 Nov 2020 15:34:03 +0100
> > Christian Grothoff <groth...@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.
