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: HTTP/3 options
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 5 Jan 2023 16:09:20 +0100 (CET)
On Thu, 5 Jan 2023, Timothe Litt wrote:
> The gnu parsers that accept = also take the argument as the following word.
curl never used any gnu parser.
>> Maybe. That would introduce challenges when you run a bazillion different
>> concurrent curls
> I don' t think that's the typical (or common) user case.
For soon 25 years, the curl you invoke in one shell is completely and totally
unrelated to and independent of the curl you invoke in a second shell. There
is no shared state unless you explcitily make them have it. This is not a
niche use case, it's rather a fundamental design principle.
Changing this should not be done without very careful considerations. I think
sharing an alt-svc cache by default between invokes risks causing problems. I
don't think most curl users even know what alt-svc is or how it might affect
their curl transfers.
> As a principle, I'd rather have curl try the most efficient
> protocols/options, and if it fails, let the user say '--no-something' than
> have the user say 'use this' 'use that' 'use something else'.
That's not really a principle curl uses though. By default it doesn't enable
cookies, it doesn't follow redirects, it doesn't do compression, enable HSTS
etc. It does the basic by default and then lets the user add bells and
whistles on demand.
curl isn't a "just get me this file" tool. It is slightly more than that.
Date: Thu, 5 Jan 2023 16:09:20 +0100 (CET)
On Thu, 5 Jan 2023, Timothe Litt wrote:
> The gnu parsers that accept = also take the argument as the following word.
curl never used any gnu parser.
>> Maybe. That would introduce challenges when you run a bazillion different
>> concurrent curls
> I don' t think that's the typical (or common) user case.
For soon 25 years, the curl you invoke in one shell is completely and totally
unrelated to and independent of the curl you invoke in a second shell. There
is no shared state unless you explcitily make them have it. This is not a
niche use case, it's rather a fundamental design principle.
Changing this should not be done without very careful considerations. I think
sharing an alt-svc cache by default between invokes risks causing problems. I
don't think most curl users even know what alt-svc is or how it might affect
their curl transfers.
> As a principle, I'd rather have curl try the most efficient
> protocols/options, and if it fails, let the user say '--no-something' than
> have the user say 'use this' 'use that' 'use something else'.
That's not really a principle curl uses though. By default it doesn't enable
cookies, it doesn't follow redirects, it doesn't do compression, enable HSTS
etc. It does the basic by default and then lets the user add bells and
whistles on demand.
curl isn't a "just get me this file" tool. It is slightly more than that.
-- / 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.se/mail/etiquette.htmlReceived on 2023-01-05