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). 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.) Is that your motivation, or what is the issue you're trying to solve here?
signature.asc
Description: OpenPGP digital signature
