Sorry, I have an error on my writting:
to now trigger I ment to say to not trigger
2013/1/11 Alexandre Filgueira alexfilgue...@cinnarch.com
Content-Length: 369
My guess this is the difference. The one redirect has a body, and the
other doesn't:
I see... so, if I want to bypass that to just
Yang Tse yangs...@gmail.com wrote:
config-platform.h in this case (config-win32.h) should be defining
USE_ARES and verifying that USE_THREADS_WIN32 is not defined when
WITH_ARES or ENABLE_ARES is defined.
It's been a long time since I was involved in the
asyn*.c / resolver stuff. Many other
Hi Oscar,
So great news, your suggestion worked, I added the line;
curl_easy_setopt(curl, CURLOPT_SSL_OPTIONS, CURLSSLOPT_ALLOW_BEAST);
and this works. The CURLOPT_SSL_CIPHER_LIST suggestion didn't seem to do
much in terms of this issue but its working now so just happy with that.
Thanks so
On Fri, 11 Jan 2013, Yang Tse wrote:
I'll study your trace, compare with mine and later on start to debug this.
Just wanted now to handle you all logs for test 64.
Can you first check and see if there's a time descripancy between the trace64
log and the http_server.log ? I can't make sense
I'm not sure it matters, but the comment in asyn-ares.c is
wrong:
/*
...
* Returns: CURLE_OK always!
*/
int Curl_resolver_getsock(struct connectdata *conn,
curl_socket_t *socks,
int numsocks)
{
..
int max =
On Fri, Jan 11, 2013, Daniel Stenberg wrote:
Can you first check and see if there's a time descripancy between the
trace64 log and the http_server.log ? I can't make sense of the times in
there:
These are the best kind of timestamps we can get on this kind of
'system', not too bad accuracy
On Fri, Jan 11, 2013 at 09:38:13AM +0100, Alexandre Filgueira wrote:
Sorry, I have an error on my writting:
to now trigger I ment to say to not trigger
2013/1/11 Alexandre Filgueira alexfilgue...@cinnarch.com
Content-Length: 369
My guess this is the difference. The one
