Thanks for getting back. Here is some background to the application in its
current state -
The application has X worker threads that receives 1000s of concurrent
requests per second.
As part of handling these incoming requests, the X worker threads need to
make a callout to an external HTTP
On 7/10/2015 2:06 AM, Rajalakshmi Iyer wrote:
Thanks for getting back. Here is some background to the application in
its current state -
The application has X worker threads that receives 1000s of concurrent
requests per second.
As part of handling these incoming requests, the X worker
Thanks!
I am planning to create X easy handles for the X worker threads and add
them to the multi handle before executing curl_multi_perform in a loop.
These X worker threads would then continuously change the URL (same
external server but with different query parameters) for the X easy handles
On Wed, 8 Jul 2015, Dr. Roger Cuypers wrote:
So simplified that means that verify peer has a similar functionality like
SSL_get_verify_result in OpenSSL while verify host checks the common name?
Verify peer checks that the cert is signed by a CA, verify host makes sure the
cert contains the
On Tue, 7 Jul 2015, Michael Kaufmann wrote:
Multi handles also provide a connection cache, but they do not provide an
SSL session cache. Is this on purpose (security), or is this just not
implemented yet?
The latter. I can't see any reason why sharing the sessions would be a
problem.
--
On Fri, 10 Jul 2015, Ray Satiro via curl-library wrote:
Generally there is something in libcurl I'm unclear about (I've asked on the
list before but didn't get a reply addressing it) which is it seems that it's
acceptable behavior for curl_multi_perform to always be performing and not
return
On Tue, 7 Jul 2015, Daniel Hardman wrote:
I have submitted a pull request. However, please note:
Since libidn now shipped a fixed version, do we still need this check or any
portion of it?
--
/ daniel.haxx.se
---
List admin:
Attached is an attempt at a sample program that creates 2 threads each
with an easy handle that is added to the global multi handle. It uses libuv
for socket event handling.
Each thread is supposed to continuously fetch data from an external server
(see http_get() thread function).
However,
Since libidn now shipped a fixed version, do we still need this check or
any portion of it?
A quick google didn't give me any details on libidn's fix. Do you have a
link that describes it?
--Daniel
---
List admin:
On Jul 10, 2015, at 10:24 AM, Daniel Hardman wrote:
Since libidn now shipped a fixed version, do we still need this check or any
portion of it?
A quick google didn't give me any details on libidn's fix. Do you have a link
that describes it?
They've shipped a new version but classified
We have a situation where we have a custom CA that has signed
server and client certificates.
The server certificates have CNs (like server-abcde) which
are unrelated to the URL used to access them e.g.
https://192.168.100.2:8443/;
I think I need to leave CURLOPT_SSL_VERIFYPEER turned on to
On 7/7/2015 6:33 PM, Daniel Hardman wrote:
1. The pull request is from my private fork to Ray's
check_utf8_before_libidn branch; it doesn't yet target master. This is
because I'd like at least Ray and Daniel's feedback, first.
2. I'm a bit unhappy about the lack of error propagation. Right
My approach has generally been to have one thread that does
curl_multi_perform that also selects on a pipe so it can wake up when
requests need to be added to the multi handle.
Anders
On Fri, Jul 10, 2015 at 2:38 AM, Daniel Stenberg dan...@haxx.se wrote:
On Fri, 10 Jul 2015, Ray Satiro via
On 7/10/2015 7:24 AM, Alex Bligh wrote:
We have a situation where we have a custom CA that has signed
server and client certificates.
The server certificates have CNs (like server-abcde) which
are unrelated to the URL used to access them e.g.
https://192.168.100.2:8443/;
I think I need to
14 matches
Mail list logo
