Re: [libmicrohttpd] Aync handling & message response

[Christian Grothoff]

HTTP 1.1 processes requests in-order. Clients may send us additional
requests on the same TCP connection, but MHD will only ever look at a
subsequent request after processing the previous request is complete.

I hope this clarifies.

On 08/29/2018 09:43 AM, Kunal Ekawde wrote:
> Ahh ok, getting it now, I wasn't using suspend/resume, but if client
> pipelines the requests, we would have suspended the connection, will it
> be handled ?
> Appreciate you help.
> 
> Thanks,
> Kunal
> 
> On Wed, Aug 29, 2018 at 12:47 PM Christian Grothoff  > wrote:
> 
> On 08/29/2018 08:44 AM, Kunal Ekawde wrote:
> > 3. Just after #2, when curl_multi_info_read is successful ,
> > MHD_queue_response is invoked, but it returns 0 and the easy_handle
> > state is 1.
> >
> > Can we send the response to client only from the MHD callback
> handler ?
> 
> Yes. You must call MHD_resume_connection (you should have called suspend
> before), and then queue once the callback is invoked.
> 
> > or something is missing in above ?
> 
> Nope, just "bad timing" of the call.
> 
> 
> 
> -- 
> ~Kunal


0x939E6BE1E29FC3CC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [libmicrohttpd] Aync handling & message response

[Santos Das]

Hi  Christian ,

How does this work with pipe-lining? My understanding was that the server
would still read the request but will maintain the order of response. But,
from your email it seems the server would also not read the second request
before sending a reply to the first request> ?

Is this correct?

thanks, santos

On Mon, Sep 3, 2018 at 12:41 PM Christian Grothoff 
wrote:

> HTTP 1.1 processes requests in-order. Clients may send us additional
> requests on the same TCP connection, but MHD will only ever look at a
> subsequent request after processing the previous request is complete.
>
> I hope this clarifies.
>
> On 08/29/2018 09:43 AM, Kunal Ekawde wrote:
> > Ahh ok, getting it now, I wasn't using suspend/resume, but if client
> > pipelines the requests, we would have suspended the connection, will it
> > be handled ?
> > Appreciate you help.
> >
> > Thanks,
> > Kunal
> >
> > On Wed, Aug 29, 2018 at 12:47 PM Christian Grothoff  > > wrote:
> >
> > On 08/29/2018 08:44 AM, Kunal Ekawde wrote:
> > > 3. Just after #2, when curl_multi_info_read is successful ,
> > > MHD_queue_response is invoked, but it returns 0 and the easy_handle
> > > state is 1.
> > >
> > > Can we send the response to client only from the MHD callback
> > handler ?
> >
> > Yes. You must call MHD_resume_connection (you should have called
> suspend
> > before), and then queue once the callback is invoked.
> >
> > > or something is missing in above ?
> >
> > Nope, just "bad timing" of the call.
> >
> >
> >
> > --
> > ~Kunal
>

Re: [libmicrohttpd] Aync handling & message response

[Christian Grothoff]

Hi Santos,

MHD simply doesn't read the next request (at least not intentionally,
bits may end up in our read buffer but won't be looked at). But the
kernels may already buffer subsequent requests.

Happy hacking!

Christian

On 09/03/2018 10:30 AM, Santos Das wrote:
> Hi  Christian ,
> 
> How does this work with pipe-lining? My understanding was that the
> server would still read the request but will maintain the order of
> response. But, from your email it seems the server would also not read
> the second request before sending a reply to the first request> ?
> 
> Is this correct?
> 
> thanks, santos
> 
> On Mon, Sep 3, 2018 at 12:41 PM Christian Grothoff  > wrote:
> 
> HTTP 1.1 processes requests in-order. Clients may send us additional
> requests on the same TCP connection, but MHD will only ever look at a
> subsequent request after processing the previous request is complete.
> 
> I hope this clarifies.
> 
> On 08/29/2018 09:43 AM, Kunal Ekawde wrote:
> > Ahh ok, getting it now, I wasn't using suspend/resume, but if client
> > pipelines the requests, we would have suspended the connection,
> will it
> > be handled ?
> > Appreciate you help.
> >
> > Thanks,
> > Kunal
> >
> > On Wed, Aug 29, 2018 at 12:47 PM Christian Grothoff
> mailto:groth...@gnunet.org>
> > >> wrote:
> >
> >     On 08/29/2018 08:44 AM, Kunal Ekawde wrote:
> >     > 3. Just after #2, when curl_multi_info_read is successful ,
> >     > MHD_queue_response is invoked, but it returns 0 and the
> easy_handle
> >     > state is 1.
> >     >
> >     > Can we send the response to client only from the MHD callback
> >     handler ?
> >
> >     Yes. You must call MHD_resume_connection (you should have
> called suspend
> >     before), and then queue once the callback is invoked.
> >
> >     > or something is missing in above ?
> >
> >     Nope, just "bad timing" of the call.
> >
> >
> >
> > --
> > ~Kunal
> 


0x939E6BE1E29FC3CC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[libmicrohttpd] Web Socket disconnect behaviour

[Paul Topley]

Hi,


I am using mhd as a restful server as well as handling websockets via the 
connection upgrade mechanism that mhd utilises.


The initial handshake, where I interpret a particular GET request and add a 
responce denoted with MHD_HTTP_HEADER_UPGRADE to state that it should be 
upgraded.


The callback registered with MHD_create_response_for_upgrade gets called as 
expected, providing a socket that I can use to communicate with the client.


This all works great, but there is one particular situation im not sure how to 
handle.  When there is an unexpected disconnect in the socket between client 
and server, which isnt instigated by either (lets say the server crashes, 
ethernet disconnect etc), im not sure how to re-establish the connection 
between then two.


I have tried firing off another upgrade response from the server when a socket 
disconnect is detected, but the same socket int which had just died is passed 
back to my handler, which subsequently returns zero when I call recv to get 
data.


Is there anything else I should be doing?


Regards


Paul