Daniel Stenberg (Thu, 2 Aug 2018 23:32:04 +0200 (CEST)):
>>Jan Ehrhardt's XP test was really slow and if we exclude that from the
>>results, the average patched result goes down to 46%.
>
>I also have a Windows 8.1 64-bits running in a Virtualbox on the Wondows
>2008 R2 server. No speed
Daniel Stenberg (Thu, 2 Aug 2018 23:32:04 +0200 (CEST)):
>Jan Ehrhardt's XP test was really slow and if we exclude that from the
>results, the average patched result goes down to 46%.
I also have a Windows 8.1 64-bits running in a Virtualbox on the Wondows
2008 R2 server. No speed improvement.
On Thu, 2 Aug 2018, Gisle Vanem wrote:
But that server is 19 hops away. Testing with the same
file via ftp to my server in Denmark (11 hops) shows a
bit worse result:
running vanilla...
start:0,406000 total:1,219000
running patched...
start:0,359000 total:1,531000
Seems ftp is maxing my
Marcel Raad wrote:
Microsoft Windows [Version 10.0.16299.547]
generating test file...
running vanilla...
start:0,656000 total:4,844000
running patched...
start:0,516000 total:1,797000
Very good improvement on http here:
Microsoft Windows [Version 10.0.17134.191]
generating test file...
> -Original Message-
> From: curl-library On Behalf Of Marcel
> Raad
> Sent: Donnerstag, 2. August 2018 19:48
> To: libcurl development
> Cc: curl users
> Subject: RE: Windows users! Help us test upload performance tuning?
>
> Looks good here (Windows 10 Pro Preview, Germany, 400/20
> -Original Message-
> From: curl-library On Behalf Of Daniel
> Stenberg
> Sent: Donnerstag, 2. August 2018 14:53
> To: libcurl hacking
> Cc: curl users
> Subject: Windows users! Help us test upload performance tuning?
>
> Please note that we would *love* your assistance here if you're
Daniel Stenberg (Thu, 2 Aug 2018 14:52:51 +0200 (CEST)):
>We want to have more user's experience and results from tests to determine how
>we should make curl make uploads on windows as fast as possible.
From Windows 2008 R2, Amsterdam, NL:
Microsoft Windows [Version 6.1.7601]
generating test
Daniel Stenberg in gmane.comp.web.curl.library (Thu, 2 Aug 2018 14:52:51
+0200 (CEST)):
>We want to have more user's experience and results from tests to determine how
>we should make curl make uploads on windows as fast as possible.
Windows 7, from Amsterdam, NL
Microsoft Windows [Version
On Thu, 2 Aug 2018, Geoff Beier wrote:
The setters would be important to us. I might be bikeshedding here, but the
ability to add to the query would be very nice. So something like
curl_url_query_append(urlp, "numitems", 3)
That ("numitems", 3) approach is very specific for adding a
We use the uriparser library Radu Hociung mentioned primarily because there
was nothing analogous in curl.
The setters would be important to us. I might be bikeshedding here, but the
ability to add to the query would be very nice. So something like
curl_url_query_append(urlp, "numitems", 3)
An
On Thu, 2 Aug 2018, Dan Fandrich wrote:
I found the reason: commit 4b414249 "lib: don't export all symbols, just
everything curl_*" This commit completely ignores --disable-symbol-hiding and
ends up trying to do what it does but in poorer fashion.
Lovely, thanks! Here's my attempt at fixing
Hello!
Please note that we would *love* your assistance here if you're a Windows user
and can offer a few moments of your time to run a few tests on a few Windows
versions and tell us the outcome! Here's a simple way to help us make curl
better without doing any coding at all! =)
We want to
On Wed, 1 Aug 2018, Radu Hociung wrote:
a "URL handling" API in libcurl
This wheel has already been invented. [1]
[1] https://uriparser.github.io/
Are you suggesting this uses an API that would be worth getting inspiration
from? Personally I don't see a lot I like there...
(Dan already
On Thu, 2 Aug 2018, Dan Fandrich wrote:
My first thought it that it's pretty long-winded. I can't think of many
situations where you might want only one part of a URL, like the port, but
don't want e.g. the host, or the query without the path. What was in the back
of my mind for such an API was
On Thu, 2 Aug 2018, Bernhard Jaeger wrote:
> All libcurl options are documented since the version they are introduced! We
> even have tests that make sure we can't forget that.
As a sidenote CURLOPT_TLS13_CIPHERS was already listed at
https://curl.haxx.se/libcurl/c/curl_easy_setopt.html
Thank you for your answer.
I misunderstood the option.
> All libcurl options are documented since the version they are introduced! We
> even have tests that make sure we can't forget that.
As a sidenote CURLOPT_TLS13_CIPHERS was already listed at
On Thu, 2 Aug 2018, Bernhard Jaeger wrote:
Until libcurl 7.60 the CURLOPT_TLS13_CIPHERS option was necessary to use TLS 1.3
with libcurl.
No! CURLOPT_TLS13_CIPHERS was introduced in 7.61.0 (see
https://curl.haxx.se/changes.html#7_61_0). If you used it with a prior libcurl
version, it did
On Thu, Aug 02, 2018 at 08:27:14AM +0200, Dan Fandrich wrote:
> On Wed, Aug 01, 2018 at 07:56:47AM +0200, Ran Mozes wrote:
> > Thanks for confirming the issue.
> >
> > Any ideas how to patch the make process in order to work around the issue?
>
> It looks to me like libtool is doing this on its
Hi,
Until libcurl 7.60 the CURLOPT_TLS13_CIPHERS option was necessary to use TLS 1.3 with libcurl.
However the option was not documented so I assumed it was a boolean to toggle tls 13 on and I set the option like this:
curl_easy_setopt(curl, CURLOPT_TLS13_CIPHERS, 1L);
Which worked I
On Wed, Aug 01, 2018 at 11:54:56PM -0500, Radu Hociung wrote:
> On 01/08/2018 5:17 PM, Daniel Stenberg wrote:
> > a "URL handling" API in libcurl
>
> This wheel has already been invented. [1]
The main point of having a libcurl API has to do with reducing security issues
due to differences in URL
On 01/08/2018 5:17 PM, Daniel Stenberg wrote:
> a "URL handling" API in libcurl
This wheel has already been invented. [1]
Cheers.
Radu.
[1] https://uriparser.github.io/
---
Unsubscribe:
yes, I think passing around a struct with this information (and able
to get uri from its parts) would be useful would be more useful then
just direct url construction ... that way one could represent a common
base uri and modify it by just setting new path (in that respect we
may want ability to
On Wed, Aug 01, 2018 at 07:56:47AM +0200, Ran Mozes wrote:
> Thanks for confirming the issue.
>
> Any ideas how to patch the make process in order to work around the issue?
It looks to me like libtool is doing this on its own now for some reason. This
is an ugly workaround, but it should work.
23 matches
Mail list logo
