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: Christian Grothoff
Subject: Re: [libmicrohttpd] upgrading and life cycle of sockets
Date: Tue, 24 Nov 2020 16:01:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

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).

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?


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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