--- Begin Message ---
|
Subject: |
Re: Question about libmicrohttp |
|
Date: |
Thu, 13 Sep 2007 12:51:41 -0600 |
|
User-agent: |
KMail/1.9.7 |
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.
> --------------------------------------------------------
--- End Message ---