[RELEASE] curl 8.1.2
Hello friends. The release frequency has been intense recently but with a little luck we might be able to slow down back to the regular scheduling after this one. As always, get the latest curl from https://curl.se - enjoy! curl and libcurl 8.1.2 Public curl releases: 219 Command line options: 251 curl_easy_setopt() options: 302 Public functions in libcurl: 91 Contributors: 2888 This release includes the following bugfixes: o configure: quote the assignments for run-compiler [1] o configure: without pkg-config and no custom path, use -lnghttp2 [8] o curl: cache the --trace-time value for a second [9] o http2: fix EOF handling on uploads with auth negotiation [7] o http3: send EOF indicator early as possible [11] o lib1560: verify more scheme guessing [5] o lib: remove unused functions, make single-use static [3] o libcurl.m4: remove trailing 'dnl' that causes this to break autoconf [10] o libssh: when keyboard-interactive auth fails, try password [4] o misc: fix spelling mistakes [2] o page-header: mention curl version and how to figure out current release [13] o page-header: minor wording polish in the URL segment [12] o scripts/singleuse.pl: add more API calls o urlapi: remove superfluous host name check [6] This release includes the following known bugs: o see docs/KNOWN_BUGS (https://curl.se/docs/knownbugs.html) Planned upcoming removals include: o gskit o NSS o support for space-separated NOPROXY patterns o support for the original legacy mingw version 1 See https://curl.se/dev/deprecate.html for details This release would not have looked like this without help, code, reports and advice from friends like these: Aleksander Mazur, Christian Hesse, correctmost on github, Dan Fandrich, Daniel Stenberg, Emanuele Torre, Gisle Vanem, Kev Jackson, musvaage on github, Sergey Fionov, Stefan Eissing, Viktor Szakats, 左潇峰 (13 contributors) References to bug reports and discussions on issues: [1] = https://curl.se/bug/?i=11179 [2] = https://curl.se/bug/?i=11171 [3] = https://curl.se/bug/?i=11174 [4] = https://curl.se/bug/?i=11196 [5] = https://curl.se/bug/?i=11219 [6] = https://curl.se/bug/?i=11195 [7] = https://curl.se/bug/?i=11194 [8] = https://curl.se/bug/?i=11186 [9] = https://curl.se/bug/?i=11211 [10] = https://curl.se/bug/?i=11212 [11] = https://curl.se/bug/?i=11205 [12] = https://curl.se/bug/?i=11217 [13] = https://curl.se/bug/?i=11216 -- / 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/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: multi interface with hsts cache
On Mon, May 29, 2023 at 11:41:04PM +0200, Przemysław Sobala via curl-library wrote: > If I understand the documentation correctly, the HSTS cache is applied to each > curl easy handle and it's read and written on each easy handle open and close > action. > I'd like to use the in-memory cache as reading and writing a cache file on > every easy handle is redundant in my opinion and can slow down my service. > 1. How can I configure the in-memory cache for easy handles in Multi > Interface? You're probably looking for the share interface: https://curl.se/libcurl/c/CURLSHOPT_SHARE.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
multi interface with hsts cache
Hello I've been successfully using curl multi interface with libuv in my service for 24/7 download requests. Now I want to benefit from caching HSTS responses to reduce the number of HTTP->HTTPS redirects. If I understand the documentation correctly, the HSTS cache is applied to each curl easy handle and it's read and written on each easy handle open and close action. I'd like to use the in-memory cache as reading and writing a cache file on every easy handle is redundant in my opinion and can slow down my service. 1. How can I configure the in-memory cache for easy handles in Multi Interface? My tests show that setting CURLOPT_HSTS_CTRL option to CURLHSTS_ENABLE is not enough and only setting the cache file path will bring the expected result. 2. Is it possible to populate the in-memory cache when my service starts, operate on this cache (read & write) during download requests, and dump to file when my service stops, so that it can be populated again on the next restart? -- Bez regards Przemysław Sobala -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: CURLINFO_APPCONNECT_TIME_T in HTTP 2
We are using version 7.81.0. I'll dig into this piece to see if that is what is happening: "or if a new connection with the need to re-authenticate at the proxy is done" I didn't question the assumption it's cached. Thanks for pointing that out. On Sat, May 27, 2023 at 6:14 AM Stefan Eissing via curl-library < curl-library@lists.haxx.se> wrote: > Addendum: I speak of a recent curl version. If you use an older libcurl, > please state the version. > > > Am 27.05.2023 um 12:00 schrieb Stefan Eissing via curl-library < > curl-library@lists.haxx.se>: > > > > > > > >> Am 26.05.2023 um 23:22 schrieb Babacar Ndiaye via curl-library < > curl-library@lists.haxx.se>: > >> > >> Hi: > >> > >> The setup we have is TLS in TLS HTTPS with proxy client authentication. > As suggested in the docs, we create one multi handler, keep it around to > leverage the connection caching, and keep adding/removing easy handles to > service the requests. > >> > >> When the transfer is done with HTTP 1.1, what I get out of > CURLINFO_APPCONNECT_TIME_T with curl_easy_getinfo() makes sense to me. > Since there is connection reuse, the average is low (100 microsec). > >> > >> Now when the transfer is done with HTTP 2, that average is big (200 > millisec). When I do it the other way, make/destroy one easy for each > request, I get that same 200 millisec. > >> > >> Does CURLINFO_APPCONNECT_TIME_T mean the same thing for in HTTP 1.1 and > 2? > > > > Yes, it is the time for handshaking the connection to the origin, not > the proxy, server. It's the same code for both HTTP versions. > > > > The question is then if the connection gets reused in your setup as you > think it should, or if a new connection with the need to re-authenticate at > the proxy is done. That would be my suspicion here. > > > > Kind Regards, > > Stefan > > > > > > > >> > >> Thanks for your help. > >> -- > >> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > >> Etiquette: https://curl.se/mail/etiquette.html > > > > -- > > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > > Etiquette: https://curl.se/mail/etiquette.html > > > -- > Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library > Etiquette: https://curl.se/mail/etiquette.html > -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
