Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Fewer mallocs is better, episode #47
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 5 Feb 2022 01:23:28 +0100
Den lör 5 feb. 2022 kl 00:38 skrev Henrik Holst <
henrik.holst_at_millistream.com>:
>
>
> Den fre 4 feb. 2022 kl 08:00 skrev Daniel Stenberg <daniel_at_haxx.se>:
>
>> On Fri, 4 Feb 2022, Henrik Holst wrote:
>>
>> > Which leaves 53 strlen calls for curl.se and 490 for google.com, for
>> curl.se
>> > these are probably "no issue" but still no idea where the 490 ones for
>> > google.com comes from (the traces only shows that strlen was called,
>> not on
>> > which string it was called so the digging is a bit time consuming).
>>
>> I suspect the reason for this difference might be the SAN name checks for
>> the
>> server certificate, since those name checks (when built to use OpenSSL)
>> are
>> done by curl code and the google.com servers have a rather large amount
>> of
>> names to check. See lib/hostcheck.c:Curl_cert_hostcheck()
>>
> Looks like for google.com half of them comes from the cert check,
> hostmatch() is called 220 times for google.com and only 2 times for
> curl.se.
>
> Half of those strlen calls (111 for google.com) can be easily removed and
> I'll post a patch for that later.
>
On the other hand this only happens for google.com with the redirect, for
the proper www.google.com and curl.se and some other domains that I've
tested hostmatch() is only
called about 2 times so my planned patch here that would remove 111 calls
to strlen will only remove 1 such call for what looks like every other site
so I think that I have been
blinded a bit by that google.com is exceptionally bad in how it sends its
certificate chain. So this feels like a dead end for now.
/HH
>
>>
>> --
>>
>> / daniel.haxx.se
>> | Commercial curl support up to 24x7 is available!
>> | Private help, bug fixes, support, ports, new features
>> | https://curl.se/support.html
>>
>
Date: Sat, 5 Feb 2022 01:23:28 +0100
Den lör 5 feb. 2022 kl 00:38 skrev Henrik Holst <
henrik.holst_at_millistream.com>:
>
>
> Den fre 4 feb. 2022 kl 08:00 skrev Daniel Stenberg <daniel_at_haxx.se>:
>
>> On Fri, 4 Feb 2022, Henrik Holst wrote:
>>
>> > Which leaves 53 strlen calls for curl.se and 490 for google.com, for
>> curl.se
>> > these are probably "no issue" but still no idea where the 490 ones for
>> > google.com comes from (the traces only shows that strlen was called,
>> not on
>> > which string it was called so the digging is a bit time consuming).
>>
>> I suspect the reason for this difference might be the SAN name checks for
>> the
>> server certificate, since those name checks (when built to use OpenSSL)
>> are
>> done by curl code and the google.com servers have a rather large amount
>> of
>> names to check. See lib/hostcheck.c:Curl_cert_hostcheck()
>>
> Looks like for google.com half of them comes from the cert check,
> hostmatch() is called 220 times for google.com and only 2 times for
> curl.se.
>
> Half of those strlen calls (111 for google.com) can be easily removed and
> I'll post a patch for that later.
>
On the other hand this only happens for google.com with the redirect, for
the proper www.google.com and curl.se and some other domains that I've
tested hostmatch() is only
called about 2 times so my planned patch here that would remove 111 calls
to strlen will only remove 1 such call for what looks like every other site
so I think that I have been
blinded a bit by that google.com is exceptionally bad in how it sends its
certificate chain. So this feels like a dead end for now.
/HH
>
>>
>> --
>>
>> / daniel.haxx.se
>> | Commercial curl support up to 24x7 is available!
>> | Private help, bug fixes, support, ports, new features
>> | https://curl.se/support.html
>>
>
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-05