curl-library
Re: A strange problem on IOS(Empty reply from server) Nick Zitzmann (2013-04-09)
Date: Wed, 10 Apr 2013 08:06:36 +0000
Hi Nick Zitzmann,
Currently the code I used is already what you suggested(I.E.,http://seiryu.home.comcast.net/libcurl-ios.html). The process is like this; 1. I firstly download the "pre-compiled binaries" which is "Download libcurl for iOS 7.29.0v2" ",and found the problem. 2. Then, I download the source code which is "curl 7.29.0, Released on the 6th of Febrary 2013", compile by myself, then I found the same problem. 3. Here is the method to upload the image. .... FILE* fp = fopen( strUtf8FileName.c_str(), "rb" );
if (NULL == fp)
{
ostringstream ostrm;
ostrm << "cannot open local file \"" << strUtf8FileName << "\"";
m_peerMsg = ostrm.str();
return false;
}
long fileSize = 0;
fseek( fp, 0, SEEK_END );
fileSize = ftell(fp);
fseek( fp, 0, SEEK_SET );
curl_easy_setopt( m_curl, CURLOPT_WRITEFUNCTION, _curl_OnRecvText );
curl_easy_setopt( m_curl, CURLOPT_WRITEDATA, &m_peerMsg );
curl_easy_setopt( m_curl, CURLOPT_READFUNCTION, NULL );
curl_easy_setopt( m_curl, CURLOPT_INFILESIZE_LARGE, static_cast<curl_off_t>(fileSize));
curl_easy_setopt( m_curl, CURLOPT_READDATA, fp );
curl_easy_setopt( m_curl, CURLOPT_POST, 1L );
curl_easy_setopt( m_curl, CURLOPT_POSTFIELDS, NULL );
curl_easy_setopt( m_curl, CURLOPT_POSTFIELDSIZE, fileSize );
curl_easy_setopt( m_curl, CURLOPT_URL, m_target.c_str() );
curl_easy_setopt( m_curl, CURLOPT_HTTPHEADER, m_headers.empty() ? NULL :_loadHeaders() );
// perform
CURLcode result = curl_easy_perform(m_curl);
// clean up
curl_easy_setopt( m_curl, CURLOPT_WRITEFUNCTION, NULL );
curl_easy_setopt( m_curl, CURLOPT_WRITEDATA, NULL );
curl_easy_setopt( m_curl, CURLOPT_READFUNCTION, NULL );
curl_easy_setopt( m_curl, CURLOPT_INFILESIZE_LARGE, 0);
curl_easy_setopt( m_curl, CURLOPT_READDATA, NULL );
curl_easy_setopt( m_curl, CURLOPT_POST, 0L );
curl_easy_setopt( m_curl, CURLOPT_POSTFIELDS, NULL );
curl_easy_setopt( m_curl, CURLOPT_POSTFIELDSIZE, 0 );
curl_easy_setopt( m_curl, CURLOPT_URL, NULL );
fclose(fp);
fp = NULL; ... 4. Here is code I traced. 1. I sending a image which size is 341623 bytes;
2. I found the fund "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; and after last time invoked this function(it wait the reply from socket), 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.
So it seems a new bug?
Thanks!B.R.
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>
> From: curl-library-request_at_cool.haxx.se
> Subject: curl-library Digest, Vol 92, Issue 23
> To: curl-library_at_cool.haxx.se
> Date: Wed, 10 Apr 2013 07:59:42 +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] Utils: Fix lost OpenSSL output with "-t". (Guenter)
> 2. Re: [patch] tailmatch() returns true for invalid host.
> (YAMADA Yasuharu)
> 3. Re: Name lookup/DNS resolution mechanism of libcurl (Yang Tse)
> 4. Re: curl mingw compile and shared v/s static libraries? (Yang Tse)
> 5. RE: curl-library Digest, Vol 92, Issue 21 (zhangyongchao)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Apr 2013 01:30:17 +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: <5164A489.3020203_at_gknw.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi Richard,
> On 10.04.2013 01:15, Richard Michael wrote:
> > Sorry you've had to spend time on this.
> naaa, no sorry - we thank you that you found the bug!!
> And even with your patch it was already better than before cause it was
> completely broken; with you patch it worked at least on Linux ...
>
> if you have a spare cpu cycle perhaps you can test the current version
> if it still works fine for ya?
> diff:
> http://svwe10.itex.at/cgit/cgit.cgi/curl.git/commit/?id=577703495e2ed11c4470f2636fae0c84f0c03bbd
> raw file:
> http://svwe10.itex.at/cgit/cgit.cgi/curl.git/plain/lib/mk-ca-bundle.pl?id=577703495e2ed11c4470f2636fae0c84f0c03bbd
>
> thanks!
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 Apr 2013 10:25:56 +0900
> From: YAMADA Yasuharu <yasuharu.yamada_at_access-company.com>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: [patch] tailmatch() returns true for invalid host.
> Message-ID:
> <CAJSWSJzRnX-GZHsNYPZLwuKqo02U9ehzNZRQpZ0iu3D9_JR5sg_at_mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The point is the second flag of cookie data file. This flag is tail match
> flag.
> I attach a patch for test1216. Please check it.
>
> Best regards,
> thanks
> ===============
> YAMADA Yasuharu
> ACCESS CO., LTD.
> Yasuharu.Yamada_at_access-company.com
>
>
>
>
> 2013/4/9 Daniel Stenberg <daniel_at_haxx.se>
>
> > 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
> > ------------------------------**------------------------------**-------
> > List admin: http://cool.haxx.se/list/**listinfo/curl-library<http://cool.haxx.se/list/listinfo/curl-library>
> > Etiquette: http://curl.haxx.se/mail/**etiquette.html<http://curl.haxx.se/mail/etiquette.html>
> >
>
> --
> .
>
> ________________________________________
> The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged.
> This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited.
> If you are not the intended recipient, please immediately notify the sender by reply e-mailer and delete this message and its attachments, if any.
> Thank you for your cooperation.
> ________________________________________
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cool.haxx.se/pipermail/curl-library/attachments/20130410/071362a6/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test1216.diff
> Type: application/octet-stream
> Size: 550 bytes
> Desc: not available
> URL: <http://cool.haxx.se/pipermail/curl-library/attachments/20130410/071362a6/attachment-0001.obj>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 10 Apr 2013 04:40:01 +0200
> From: Yang Tse <yangsita_at_gmail.com>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: Name lookup/DNS resolution mechanism of libcurl
> Message-ID:
> <CAH23gUTjg7O8evJ3c3++7+kvKRikHdqJggAcABDPFRPQGk69dA_at_mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi G?n,
>
> On Wed, Apr 10, 2013, Guenter <lists_at_gknw.net> wrote:
>
> > honestly I'm not happy with that hack, and if someone has something better
> > in mind please speak up!
>
> Modify Makefile.m32 in order to make it define one out of three
> possibilities "ENABLE_ARES", "ENABLE_SYNC_DNS" or
> "ENABLE_THREADS_WIN32".
>
> Modify config-win32.h in a way such that when above mentioned macros
> are defined config-win32.h defines appropriate USE_ARES,
> USE_THREADS_WIN32 or none of these two.
>
> This decoupling should also allow to retain default and previous
> behaviour of config-win32.h
>
> HTH
> --
> -=[Yang]=-
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 10 Apr 2013 04:56:12 +0200
> From: Yang Tse <yangsita_at_gmail.com>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: curl mingw compile and shared v/s static libraries?
> Message-ID:
> <CAH23gURNQGY7seaTPxrg6Sds68Yns1oEC2rVLzDSPHOM+aPQGA_at_mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Apr 9, 2013, Ben Greear <greearb_at_candelatech.com> wrote:
>
> > I updated to the latest curl recently and now my mingw build
> > is different.
> > [...]
> > Now, it does not. I notice that it appears to only be able to do
> > shared OR static libraries...I am pretty sure it used to do both.
> >
> > Is this on purpose?
>
> If when you mention "mingw build" you are using Makefile.m32 files,
> I'm not sure what has changed there lately.
>
> If when you mention "mingw build" you are running configure script and
> using mingw compiler, then yes, the change is on purpose. libtool and
> automake can not handle separate different compiler or preprocessor
> flags when building or using shared and static libraries. As a result
> of this we were mis-compiling and mis-using the static library
> version, although this wasn't obvious given that automake generated
> makefiles silence static build output when also building shared
> library.
>
> HTH
> --
> -=[Yang]=-
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 10 Apr 2013 05:59:35 +0000
> From: zhangyongchao <zhangyc10_at_hotmail.com>
> To: "curl-library_at_cool.haxx.se" <curl-library_at_cool.haxx.se>
> Subject: RE: curl-library Digest, Vol 92, Issue 21
> Message-ID: <BLU162-W16FB64EFF126D24924A5EAEC70_at_phx.gbl>
> Content-Type: text/plain; charset="gb2312"
>
> 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
> > ********************************************
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://cool.haxx.se/pipermail/curl-library/attachments/20130410/c942a549/attachment.html>
>
> ------------------------------
>
> 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 23
> ********************************************
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-04-10