Re: [libmicrohttpd] Question about libmicrohttp

[Christian Grothoff]

You will create a post processor for each POST request.  I would not use 
a "static" pointer for it.  Instead, you might want to store it (possibly 
with other data) in the last, "*unused", argument of your access handler, so 
that you can readily use it each time more POST data arrives.

As for writing the AccessHandlerCallback function, I again refer you to the 
testcases.  Here is an example (from daemontest_post) that will work and not 
give you the internal application error:

static int
ahc_echo (void *cls,
          struct MHD_Connection *connection,
          const char *url,
          const char *method,
          const char *version,
          const char *upload_data, unsigned int *upload_data_size,
          void **unused)
{
  static int eok;
  struct MHD_Response *response;
  struct MHD_PostProcessor *pp;
  int ret;

  if (0 != strcmp ("POST", method))
    {
      printf ("METHOD: %s\n", method);
      return MHD_NO;            /* unexpected method */
    }
  pp = *unused;
  if (pp == NULL)
    {
      eok = 0;
      pp = MHD_create_post_processor (connection, 1024, &post_iterator, &eok);
      *unused = pp;
    }
  MHD_post_process (pp, upload_data, *upload_data_size);
  if ((eok == 3) && (0 == *upload_data_size))
    {
      response = MHD_create_response_from_data (strlen (url),
                                                (void *) url,
                                                MHD_NO, MHD_YES);
      ret = MHD_queue_response (connection, MHD_HTTP_OK, response);
      MHD_destroy_response (response);
      MHD_destroy_post_processor (pp);
      *unused = NULL;
      return ret;
    }
  *upload_data_size = 0;
  return MHD_YES;
}

Best regards,

Christian


On Thursday 13 September 2007 02:05:42 pm you wrote:
> I was confused. To create a PostProcessor for POST, I need to provide
> Connection object while it's only available after the daemon starts.
> If what I understood you correctly, a static pointer in
> AccessHandlerCallback should be created and new it for the first time
> when POST is received.
> That doesn't sound right to me. I believe I must miss some point.
>
> Also, in fact no matter what I put in the AccessHandlerCallback func,
> that "Internal application ...." error always pops.
>
> Please advise. Thank you!
>
> -Tianning
>
> -----Original Message-----
> From: Christian Grothoff [mailto:address@hidden
> Sent: Thursday, September 13, 2007 2:52 PM
> To: Li, Tianning (Global Equity Markets & Services Technology)
> Cc: address@hidden
> Subject: Re: Question about libmicrohttp
>
> On Thursday 13 September 2007 12:41:40 pm you wrote:
> > I am not sure whether I get you right or not. I did try several ways
>
> to
>
> > handle request. But none of them helps. In fact the soap client uses
> > POST method but I have no clue how to handle them correctly. Everytime
>
> I
>
> > got "Internal application error, closing connection." error. Not sure
> > where the request process was interrupted. Do you have any example of
> > handling POST data?
>
> Yes, there are examples in the form of testcases (daemontest_post*.c) in
> the
> code.  Please study those, essentially the main issue here is that you
> need
> to not queue a response until (0 == *upload_data_size) signals the end
> of the
> POST data.  You should create a MHD_PostProcessor the first time the
> function
> gets called and store state in "*unused" between requests.
>
> I think the main issue for you is that you need to realize that
> "ahc_echo"
> will be called *multiple* times for the same POST request/action (the
> reason
> is that not all of the data from the POST may fit into the server's
> memory,
> depending on the specifics of the application).
>
> > Below is my callback registered to MHD_start_daemon, any comments?
> > Int ahc_echo (void *cls,
> >           struct MHD_Connection *connection,
> >           const char *url,
> >           const char *method,
> >           const char *version,
> >           const char *upload_data,
> >           unsigned int *upload_data_size, void **unused)
> > {
> >   struct MHD_Response *response;
> >   int ret;
> >   FILE *file;
> >   struct stat buf;
> >
> >   cout << "============" << endl
> >        << "method:" << method << endl
> >        << "url:" << &url[1] << endl
> >        << "upload_data:" << upload_data << endl
> >        << "upload_data_size:" << *upload_data_size << endl
> >        << "version:" << version << endl
> >        << "============" << endl;
> >   if (0 == strcmp (method, "POST"))
> >   {
> >     cout << "Hello World" << endl;
> > //-------------------------------------------I don't see this stmt
> > output. Doubt the callback thread was killed due to some exception
> >     response = MHD_create_response_from_data (strlen (PAGE),
> >                                               (void *)PAGE,
> >                                               MHD_NO, MHD_NO);
> >
> >     ret = MHD_queue_response (connection, MHD_HTTP_OK, response);
> >     cout << "ret = " << ret << endl;
> >     MHD_destroy_response (response);
> >   }else
> >   {
> >  ........
> >   }
> >   return ret;
>
> You will have "ret == MHD_NO" because you queue the response far too
> early.
> Because you return MHD_NO, the connection is then terminated, which is
> not
> what you want.
>
> Best regards,
>
> Christian
>
> > }
> >
> > Thank you!
> >
> > -Tianning
> >
> > I forgot to mention that the soap message is a POST method. And based
>
> on
>
> > the comments in microhttpd.h, it does provide method to create
> > -----Original Message-----
> > From: Christian Grothoff [mailto:address@hidden
> > Sent: Thursday, September 13, 2007 12:16 PM
> > To: Li, Tianning (Global Equity Markets & Services Technology)
> > Cc: address@hidden
> > Subject: Re: Question about libmicrohttp
> >
> >
> > If the URL access handler that you provided returns "MHD_NO" (or
> > anything but
> > MHD_YES), MHD interprets this as a serious error (your application
>
> could
>
> > not
> > process the request) and then MHD will close the socket and (given
> > MHD_USE_DEBUG) print this warning.  So I'd start by checking the
>
> return
>
> > value
> > from your handler.
> >
> > Also, make sure that you queue the response only after you have
>
> received
>
> > the
> > entire request -- if you queue a response too early (i.e., when the
> > upload is
> > not yet complete), MHD_queue_response will fail (returning "MHD_NO" to
> > you).
> > I think in the fileserver_example, the code directly returns whatever
> > value
> > MHD_queue_response returned.  That's only ok because the code is for a
> > GET
> > request and so MHD_queue_response should only fail on a serious error.
> >
> > I hope this helps!
> >
> > Christian
> >
> > On Thursday 13 September 2007 10:00, you wrote:
> > > Christian,
> > >
> > > This is Tianning. I found some strange problem while playing with
> > > libmicrohttp. I have a simple test program mimic to the
> > > fileserver_example from libmicrohttp package. Also I have a simple
> >
> > soap
> >
> > > client. While sending soap request to the server, the server always
> > > complains about "Internal application error, closing connection." I
>
> am
>
> > > not sure why it happens. Could you take a look and let me know for
>
> any
>
> > > possible reason?
> > >
> > > Thank you in advance!
> > >
> > > Tianning
> > > --------------------------------------------------------
> > >
> > > This message w/attachments (message) may be privileged, confidential
> >
> > or
> >
> > > proprietary, and if you are not an intended recipient, please notify
> >
> > the
> >
> > > sender, do not use or share it and delete it. Unless specifically
> > > indicated, this message is not an offer to sell or a solicitation of
> >
> > any
> >
> > > investment products or other financial product or service, an
>
> official
>
> > > confirmation of any transaction, or an official statement of Merrill
> >
> > Lynch.
> >
> > > Subject to applicable law, Merrill Lynch may monitor, review and
> >
> > retain
> >
> > > e-communications (EC) traveling through its networks/systems. The
>
> laws
>
> > of
> >
> > > the country of each sender/recipient may impact the handling of EC,
> >
> > and EC
> >
> > > may be archived, supervised and produced in countries other than the
> > > country in which you are located. This message cannot be guaranteed
>
> to
>
> > be
> >
> > > secure or error-free. This message is subject to terms available at
> >
> > the
> >
> > > following link: http://www.ml.com/e-communications_terms/. By
> >
> > messaging
> >
> > > with Merrill Lynch you consent to the foregoing.
> > > --------------------------------------------------------
> >
> > --------------------------------------------------------
> >
> > This message w/attachments (message) may be privileged, confidential
>
> or
>
> > proprietary, and if you are not an intended recipient, please notify
>
> the
>
> > sender, do not use or share it and delete it. Unless specifically
> > indicated, this message is not an offer to sell or a solicitation of
>
> any
>
> > investment products or other financial product or service, an official
> > confirmation of any transaction, or an official statement of Merrill
>
> Lynch.
>
> > Subject to applicable law, Merrill Lynch may monitor, review and
>
> retain
>
> > e-communications (EC) traveling through its networks/systems. The laws
>
> of
>
> > the country of each sender/recipient may impact the handling of EC,
>
> and EC
>
> > may be archived, supervised and produced in countries other than the
> > country in which you are located. This message cannot be guaranteed to
>
> be
>
> > secure or error-free. This message is subject to terms available at
>
> the
>
> > following link: http://www.ml.com/e-communications_terms/. By
>
> messaging
>
> > with Merrill Lynch you consent to the foregoing.
> > --------------------------------------------------------
>
> --------------------------------------------------------
>
> This message w/attachments (message) may be privileged, confidential or
> proprietary, and if you are not an intended recipient, please notify the
> sender, do not use or share it and delete it. Unless specifically
> indicated, this message is not an offer to sell or a solicitation of any
> investment products or other financial product or service, an official
> confirmation of any transaction, or an official statement of Merrill Lynch.
> Subject to applicable law, Merrill Lynch may monitor, review and retain
> e-communications (EC) traveling through its networks/systems. The laws of
> the country of each sender/recipient may impact the handling of EC, and EC
> may be archived, supervised and produced in countries other than the
> country in which you are located. This message cannot be guaranteed to be
> secure or error-free. This message is subject to terms available at the
> following link: http://www.ml.com/e-communications_terms/. By messaging
> with Merrill Lynch you consent to the foregoing.
> --------------------------------------------------------