I trace the libcurl code, locate the problem position, but not known the root case. I strongly need your expertise. The trace result list here:
 
1. I sending an image which size is 341623 bytes;

2. I found the function "easy->result = easy->result = Curl_readwrite(easy->easy_conn, &done);" is for transferring data each time. Each timer sending (16384 about 16K) data.

3. I found each time sending is success until the last time invoked this function(it wait the reply from socket maybe), it could not get the results,until 10minutes, then,I trace found result "easy->result = CURLE_RECV_ERROR".
4. So, it is enter into this code section,
       if(done || (easy->result == CURLE_RECV_ERROR))
       {
          ¡­¡­

        /* If CURLE_RECV_ERROR happens early enough, we assume it was a race
         * condition and the server closed the re-used connection exactly when
         * we wanted to use it, so figure out if that is indeed the case.
         */
          ¡­¡­
5. And at last, invoked "Curl_http_done which print out error message "Empty reply from server".

 I hope my above information is useful to locate the root cause for me.
 An information maybe useful: I found this error is not happened each timer,If I debug step by step, it always success. But if I let it be(no break,just running),I found it's relatively easy to get wrong.
    Thanks!



> From: curl-library-request_at_cool.haxx.se
> Subject: curl-library Digest, Vol 92, Issue 21
> To: curl-library_at_cool.haxx.se
> Date: Tue, 9 Apr 2013 18:08:48 +0200
>
> Send curl-library mailing list submissions to
> curl-library_at_cool.haxx.se
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-library
> or, via email, send a message with subject or body 'help' to
> curl-library-request_at_cool.haxx.se
>
> You can reach the person managing the list at
> curl-library-owner_at_cool.haxx.se
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of curl-library digest..."
>
>
> Today's Topics:
>
> 1. Re: [patch] tailmatch() returns true for invalid host.
> (Daniel Stenberg)
> 2. Re: A strange problem on IOS(Empty reply from server)
> (Daniel Stenberg)
> 3. Re: [patch] tailmatch() returns true for invalid host.
> (Daniel Stenberg)
> 4. Recognizing a non-standard FTP response to PWD & MKD commands
> (Bill Middlecamp)
> 5. Re: --with-darwinssl on iOS ? (Nick Zitzmann)
> 6. Re: A strange problem on IOS(Empty reply from server)
> (Nick Zitzmann)
> 7. Re: [PATCH] Utils: Fix lost OpenSSL output with "-t". (Guenter)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 9 Apr 2013 14:37:17 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: [patch] tailmatch() returns true for invalid host.
> Message-ID: <alpine.DEB.2.00.1304091436360.22285_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Tue, 9 Apr 2013, YAMADA Yasuharu wrote:
>
> > I noticed that the cookie tailmatch() function returns true if following
> > case:
> > - cookie comain is example.com or .example.com.
> > - hostname is abcexample.com
>
> Thanks. Have you tried to write up a test case for the test suite that repeats
> the problem and proves your fix?
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 9 Apr 2013 15:31:16 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: A strange problem on IOS(Empty reply from server)
> Message-ID: <alpine.DEB.2.00.1304091530240.22285_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Tue, 9 Apr 2013, zhangyongchao wrote:
>
> > A strange problem here , I upload a image which the size is 341623, I trace
> > the msg, a msg "We are completely uploaded and fine" is displayed; But then,
> > it's seem dead lock no response, after about at least 3~5 minutes, libcurl
> > display "Empty reply from server curl_easy_perform failed. Server returned
> > nothing (no headers, no data)" Any idea, my code is good at Mac&Window.
>
> And you know that headers + data actually was received by the client's TCP
> stack?
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 9 Apr 2013 15:47:47 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: [patch] tailmatch() returns true for invalid host.
> Message-ID: <alpine.DEB.2.00.1304091546410.22285_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Tue, 9 Apr 2013, Daniel Stenberg wrote:
>
> > Thanks. Have you tried to write up a test case for the test suite that
> > repeats the problem and proves your fix?
>
> I wrote up test 1216 and just pushed it to the git repo. I tried to repeat
> what you described but it doesn't seem to repeat the problem. Can you see what
> you need to adjust to make the test fail?
>
> --
>
> / daniel.haxx.se
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 9 Apr 2013 14:35:42 +0000
> From: Bill Middlecamp <Bill.Middlecamp_at_quantum.com>
> To: "curl-library_at_cool.haxx.se" <curl-library_at_cool.haxx.se>
> Subject: Recognizing a non-standard FTP response to PWD & MKD commands
> Message-ID: <55EB1CAC8D35774E9318A63B4BCFE9DE26A58726_at_ppomsg1>
> Content-Type: text/plain; charset="us-ascii"
>
> I would like to request that a change be added to libcURL so that it will accept a slightly non-compliant FTPD 257 response.
>
> I have written an FTP client to interface with a customized FTP daemon in a storage appliance for the video industry. The vendor of this appliance implemented a non-RFC 959 response 257 to the PWD and MKD commands. The standard specifies the response to PWD and MKD commands be of the following form:
>
> 257<space>"<directory-name>"<space><commentary>
>
> The vendor incorrectly implemented the response in the following form:
>
> 257<space><space><commentary>"<directory-name>"
>
> I could not require that the FTP daemon be fixed and deployed, so I made a simple change to libcURL to accept the non-standard response. Without this change, libcurl can lose track of the HOME directory under the following scenario:
>
>
> 1) Set CURLOPT_FTP_FILEMETHOD to MULTICWD, and upload a temporary file to get libcurl to create the missing elements of a directory path as needed, then DELE the temporary file with a POSTQUOTE command.
>
> 2) Set CURLOPT_FTP_FILEMETHOD to NOCWD to support QUOTE commands with pathnames rooted in the user's HOME directory.
>
> I realize that this is an unusual way to use CURLOPT_FTP_FILEMETHOD, but it works with RFC 959 compliant FTP servers. Using MULTICWD allows for efficient directory-path creation, but it is very difficult to use QUOTE commands with MULTICWD since it is difficult to know either the absolute path name or the current directory for a relative path name.
>
> Following is the patch that allows the non-compliant 257 response to be parsed:
>
> --- curl-7.29.0_new/lib/ftp.c 2013-03-25 09:33:57.984270281 -0500
> +++ curl-7.29.0/lib/ftp.c 2013-01-17 15:40:43.000000000 -0600
> @@ -2873,15 +2873,6 @@
> double-quotes should be escaped by double-quotes (the
> "quote-doubling" convention).
> */
> -
> - /* scan for the first double-quote for non-standard responses */
> - while (ptr < (&(data->state.buffer) + sizeof(data->state.buffer))
> - && *ptr != '\0'
> - && *ptr != '"'
> - ) {
> - ptr++;
> - }
> -
> if('\"' == *ptr) {
> /* it started good */
> ptr++;
>
> ----------------------------------------------------------------------
> The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cool.haxx.se/pipermail/curl-library/attachments/20130409/e60be558/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 9 Apr 2013 09:51:08 -0600
> From: Nick Zitzmann <nick_at_chronosnet.com>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: --with-darwinssl on iOS ?
> Message-ID: <E06CAC9A-EBEE-4D3E-A143-0F3DD2B4E160_at_chronosnet.com>
> Content-Type: text/plain; charset=windows-1252
>
>
> On Apr 9, 2013, at 1:54 AM, Paul Joyce <pjoyce_at_we-do-it.com> wrote:
>
> > curl version: 7.28.0
> [?]
> > It says HTTPS is in the list, so configure was happy enough.
> >
> > When I attempt to compile, I get an error
> > ?./curl-7.28.0/lib/curl_darwinssl.c:905:6: Use of undeclared identifier 'SecTrustEvaluateAsync'; did you mean 'SecTrustEvaluate'?
> [?]
> > My question is can I get this to compile on iOS? The source says
> > #if defined(__MAC_10_7) || defined(__IPHONE_5_0)
> > so it seems to think it can compile on iOS.
>
> This is a known bug in 7.28.0 that was fixed in the very next release. 7.28.1 and later will build just fine on iOS.
>
> Actually, if you're using libcurl in an iOS application, you might want to wait for the next release, 7.30.0, which is coming real soon now (like today or tomorrow). It has an important Secure Transport sending bug fix, and has slightly improved security, since I removed support for insecure ciphers like NULL/anonymous/IDEA/DES.
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 9 Apr 2013 09:53:15 -0600
> From: Nick Zitzmann <nick_at_chronosnet.com>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: A strange problem on IOS(Empty reply from server)
> Message-ID: <3885A39E-EFCE-4AF6-9996-5A7A343A1FDB_at_chronosnet.com>
> Content-Type: text/plain; charset=GB2312
>
>
> On Apr 8, 2013, at 8:24 PM, zhangyongchao <zhangyc10_at_hotmail.com> wrote:
>
> > I complied 7.29.0 source code and used in iPad3.
> >
> > A strange problem here , I upload a image which the size is 341623, I trace the msg, a msg "We are completely uploaded and fine" is displayed;
> >
> > But then, it's seem dead lock no response, after about at least 3~5 minutes, libcurl display "
> > Empty reply from server
> > curl_easy_perform failed.
> > Server returned nothing (no headers, no data)"
>
> Were you using TLS? If so, then this is a known bug in the Secure Transport code that will be fixed in 7.30.0, coming real soon now. If you can't wait, then the pre-compiled binaries for iOS on my personal Web site already have the fix deployed: <http://seiryu.home.comcast.net/libcurl-ios.html>
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 09 Apr 2013 18:08:33 +0200
> From: Guenter <lists_at_gknw.net>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: [PATCH] Utils: Fix lost OpenSSL output with "-t".
> Message-ID: <51643D01.807_at_gknw.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Richard,
> On 04.04.2013 11:55, Richard Michael wrote:
> > The OpenSSL pipe wrote to the final CA bundle file, but the encoded PEM
> > output wrote to a temporary file. Consequently, the OpenSSL output was
> > lost when the temp file was renamed to the final file at script finish
> > (overwriting the final file written earlier by openssl).
> >
> > This simple fix captures openssl command output, then write to the
> > temporary file.
> > ---
> thanks, verified and just pushed!
>
> G?n.
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> curl-library mailing list
> curl-library_at_cool.haxx.se
> http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-library
>
>
> ------------------------------
>
> End of curl-library Digest, Vol 92, Issue 21
> ********************************************
                                               

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-04-10