I’ve opened bug MODLANG-71.  I have a feeling you’ll need to check 
content-length, but I am not sure.  I’m actually playing around with the source 
locally and trying to find a fix as well.  At least, a temp fix so my code will 
work J.

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Jerris
Sent: July 15, 2008 6:31 PM
To: [email protected]
Subject: Re: [Freeswitch-users] Spidermokey_curl problem? Sanity check please

 

The analysis looks good, but how in the API do we know when the response is 
complete?  Can you please open a bug on jira.freeswitch.org for this so we can 
track it.

 

Thanks

Mike

On Jul 15, 2008, at 8:12 PM, "Simon Tang" <[EMAIL PROTECTED]> wrote:

        Hello,

         

        I’ve been making Javascript curl requests and have found that larger 
requests sometimes come back incomplete.  This is what I am doing in javascript:

        ------------

        function callback(string, arg)

        {

            console_log("info", "returned body:" + string + "\n");

            return true;

        }

         

        var curl = new CURL();

        var blah = curl.run("GET", url, args, callback, arg, "");

        --------------

         

        comparing ‘string’ with tcpdump, I found that ‘string’ is definitely 
incomplete vs. tcpdump.

         

        I’ve looked into spidermokey_curl.c and found this code (excerpts):

         

        static size_t file_callback(void *ptr, size_t size, size_t nmemb, void 
*data)

        {…}

         

        curl_easy_setopt(co->curl_handle, CURLOPT_WRITEFUNCTION, file_callback);

        curl_easy_setopt(co->curl_handle, CURLOPT_WRITEDATA, (void *) co);

         

        I had the suspicion that the callback is getting a partial response and 
passing it into the JS object as a completed response:

         

        -          From 
http://curl.netmirror.org/libcurl/c/curl_easy_setopt.html: “The callback 
function will be passed as much data as possible in all invokes, but you cannot 
possibly make any assumptions. It may be one byte, it may be thousands. The 
maximum amount of data that can be passed to the write callback is defined in 
the curl.h header file: CURL_MAX_WRITE_SIZE.”  >From this, I think that it is 
the callback’s responsibility to ensure that the complete response was received 
and to save the data somewhere.

         

        To confirm my suspicion, I replaced the callback function in 
spidermonkey_curl.c with vanilla logging and took out the JSAPI references:

         

        static size_t file_callback(void *ptr, size_t size, size_t nmemb, void 
*data)

        {

            register unsigned int realsize = (unsigned int) (size * nmemb);

        switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG,"BODY 
STUFF::::::%s\n", (char*) ptr);

        return realsize;

        }

         

        I recompiled and reproduced the offending http request.  I found that 
the log is called twice, with each log comprising both pieces of the complete 
response.  When I reverted back to the original file_callback function and 
added a log in there, the log only recorded the first part of the response 
(incomplete).

         

        I’m not sure if I’m using this correctly or if my analysis is correct, 
so if someone can provide me some feedback, that’d be great.  If it’s a legit 
bug, I can file it.

         

        Simon Tang

        _______________________________________________
        Freeswitch-users mailing list
        [email protected]
        http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
        UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
        http://www.freeswitch.org

_______________________________________________
Freeswitch-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Reply via email to