Hi,
I modified the above snippet to:
if (upload_data_size && *upload_data_size != 0)
{
pCr->reqData << std::string(upload_data, *upload_data_size);
*upload_data_size = 0;
return MHD_YES;
}
which avoids 1 extra callback by MHD as opposed to earlier, till now tes
Hi Christian,
I have following code snippet:
pCr is of type ConnectionRsp -- a structure to hold the request data for
mapping on 2nd invocation of access handler callback.
'parsingReqData' is set to false initially and not updated anywhere else
apart from following mentioned.
if (!pCr->parsin
Hi Kunal,
The most common bug in this context is that you MUST set
"*upload_data_size = 0" (or to however many bytes are left) within your
httpServerAccessHandlerCb. Failure to do so will mean that MHD won't
read more of the upload. That's at least my best guess, as you only
provided a code frag
Hi Christian,
I'm using following options, single threaded external epoll:
auto mhdDaemon = MHD_start_daemon (MHD_USE_EPOLL |
MHD_ALLOW_SUSPEND_RESUME | MHD_USE_ERROR_LOG | *MHD_USE_TURB*O
| MHD_USE_DEBUG,
0,
NULL, NULL, &Server::httpServerAccessHandlerCb, t
In this case, MHD would use an eventfd instead of a pipe *if* the
platform supports it (i.e. on GNU/Linux).
On 09/06/2018 08:11 AM, Kunal Ekawde wrote:
> Hi Christian,
>
> Can you please confirm if suspend/resume wont use pipe (lfor IPC)?
> As in manual it's mentioned as:
> "Enables using MHD_sus
On 09/06/2018 08:19 AM, Kunal Ekawde wrote:
>
> Can you please provide some information on 'MHD_USE_TURBO' as I couldn't
> find any info in manual.
From the manual:
@item MHD_USE_TURBO
@cindex performance
Enable optimizations to aggressively improve performance.
Currently, the optimizations thi
Can you please provide some information on 'MHD_USE_TURBO' as I couldn't
find any info in manual.
Thanks,
Kunal
On Thu, Sep 6, 2018 at 11:41 AM Kunal Ekawde wrote:
> Hi Christian,
>
> Can you please confirm if suspend/resume wont use pipe (lfor IPC)?
> As in manual it's mentioned as:
> "Enables
Hi Christian,
Can you please confirm if suspend/resume wont use pipe (lfor IPC)?
As in manual it's mentioned as:
"Enables using MHD_suspend_connection and MHD_resume_connection,
as performing these calls requires some additional pipes to be created,
and code not using these calls should not pay th
Thanks Christian, yes I got it done :)
On Wed, Sep 5, 2018 at 3:05 PM Christian Grothoff
wrote:
> Dear Kunal,
>
> Yes, you can do all this, including raw epoll, no threads and storing
> connection details in '*cls'. I just don't have an example that does
> all this at once ;-)
>
> Happy hacking
Christian / Kunal,
Doesn't the suspend_resume_epoll.c example cover this exact case?
- Bob
On Wed, Sep 5, 2018 at 5:35 AM Christian Grothoff
wrote:
> Dear Kunal,
>
> Yes, you can do all this, including raw epoll, no threads and storing
> connection details in '*cls'. I just don't have an exam
Dear Kunal,
Yes, you can do all this, including raw epoll, no threads and storing
connection details in '*cls'. I just don't have an example that does
all this at once ;-)
Happy hacking!
Christian
On 08/27/2018 11:15 AM, Kunal Ekawde wrote:
> Hi,
>
> With ref to:
> https://lists.gnu.org/archi
Hi Christian,
Thanks for the response, yes, its clear now.
Regards,
Kunal
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 reques
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
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 co
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
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:
>
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_c
I was able to do following but have some issue in MHD_queue_response.
Scenario: Main thread having select, without any MHD threads with curl
multi integration.(updated benchmark.c)
1. Receive GET, on 2nd call of ahc_echo, saved the connection pointer and
invoked curl client to GET to another serve
18 matches
Mail list logo
