On 11/4/2015 6:54 AM, KS Lee wrote:
Thank you, Ray, for the reply.
gmane.comp.web.curl.library by Ray Satiro via curl-library / 2h
// keep unread // hide // preview
That you have the same issue with WinSSL as you do OpenSSL leads me to
believe this isn't a problem with either. You don't have this problem
without SSL?
The connection absolutely requires SSL, so it was a use-case we're
stuck with. We have used WinSSL, OpenSSL, LibreSSL - ended with the
same i.e. worked with a proxy in between, but failed with
CURLE_RECV_ERROR without the proxy.
I apologize if this was answered already but I can only
find part of the thread now. Is it possible that the reason you don't
see an issue over a proxy like Fiddler is because you didn't use it
enough to observe the issue there? In other words just because it
appears to work fine through Fiddler a few times isn't the same as
your
normal use.
We also convinced IT Security Audit to allow the proxy connection in
the interim using libcurl built with OpenSSL 1.0.2d. Has been running
fine for weeks already. Once the proxy is removed, bam, the error
returns.
This is not a solution that our auditors like at all, and are pressing
us to remove the unauthorised proxy as soon as possible.
You wrote in another e-mail "Wireshark traces for the non-proxy
scenario, it is showing a TCP disconnecting from libcurl, and then
reconnecting at every HTTP interaction with the web server. This is
normal behaviour, since keep-alive was not set." [1] Maybe the
constant
reconnection is why the issue can be more readily observed without a
proxy.
Yes, that was the hunch we went with.
When you say keep alive are you referring to TCP keepalive or
sending an actual Keep-Alive in the header which shouldn't be
necessary
with HTTP/1.1 since keepalive is the default?
We were wondering whether the proxy shielded the reconnections from
the web server. So, in some of our test cases, we enabled the
libcurl KEEP-ALIVE option and re-ran the test with the app that ran
fine with a proxy. Again, same problem.
So, what's so special about putting a proxy service in between the
libcurl-calling app, and the HTTPS web server? That has stumped us.
At this point, we're willing to try anything.
Are multiple server IPs involved? Maybe there is a problem with some
specific IP and/or the IP is not used by the proxy. Also I notice you
are using IGNORE_CONTENT_LENGTH, why? Try disabling that and see what
happens. The way that works is exactly what it says, it's going to
ignore the content length. Although I don't see this in your logs
consider the following:
- Client makes a request
- Server replies without chunked encoding or connection close.
- Client ignores content length and because there's no other indicator
(chunked, close) to go on it basically just waits around staying connected.
- Server (or something in between) severs the connection unclean.
- Client starts new connection and repeat
Now suppose that happens n times and meets some threshold where now
connections that have the chunked reply get severed that way too. The
proxy masks the sever and that's why you don't see a recv error. In
other words the proxy gets the recv error and gives you a clean close.
In your wireshark logs when you used the proxy did you capture those
packets as well? Was it a Fiddler proxy on localhost or something ?
Check for this scenario.
If you have to ignore content length you can try requesting that the
server close the connection with connection close which means sending a
header of "Connection: close". Really I wouldn't do that unless you have
to though because it sends performance down the drain. You might also
try disabling 100 expect, because your server may be too impatient for
the delay while libcurl waits for that.
So try disabling ignore_content_length. If that doesn't work and you
find you have to ignore then find out why, be really sure, and then you
could try this:
struct curl_slist *header_list = NULL;
header_list = curl_slist_append(header_list, "Expect:");
header_list = curl_slist_append(header_list, "Connection: close");
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, header_list);
You could also try switching to HTTP/1.0 just to see what happens.
curl_easy_setopt(curl, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_0);
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
