Buy commercial curl support. 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 Daniel himself.
Re: HTTPS-RR and ECH
- 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, 30 Jul 2026 17:06:19 +0200 (CEST)
On Thu, 30 Jul 2026, Michael wrote:
> Conflating browser-layer security models with programmatic transport
> utilities like curl reflects a fundamental misunderstanding of operational
> scope.
What if you build a browser using libcurl for the networking parts?
I expect no one thinks we should conflate anything, but I'm pretty sure a
large amount of curl and licburl users think we should offer the same or
similar transfer features that the browsers have.
We offer options for users to opt-in and out of features, both at build-time
and runtime to allow them to decide as much as possible.
> Interactive browser sessions differ vastly from programmatic client
> execution.
Sometimes they do, sometimes they don't. curl and libcurl offer users to make
those distinctions rather than us doing them for them.
Browser-like automation is a pretty signification chunk of curl use cases.
> As for c-ares: requiring a specific asynchronous resolver to process HTTPS
> resource records is an implementation bottleneck, not a validation of its
> design.
I must have missed all your pull-requests and work into improve curl's HTTPS
record resolving without using an external library.
> A user-developer choosing to link that dependency is simply inheriting
> structural complexity.
Linking with libcurl is already "inheriting significant structural
complexity". The key is probably to provide value that is worth more than the
complexity it contains/hides.
Date: Thu, 30 Jul 2026 17:06:19 +0200 (CEST)
On Thu, 30 Jul 2026, Michael wrote:
> Conflating browser-layer security models with programmatic transport
> utilities like curl reflects a fundamental misunderstanding of operational
> scope.
What if you build a browser using libcurl for the networking parts?
I expect no one thinks we should conflate anything, but I'm pretty sure a
large amount of curl and licburl users think we should offer the same or
similar transfer features that the browsers have.
We offer options for users to opt-in and out of features, both at build-time
and runtime to allow them to decide as much as possible.
> Interactive browser sessions differ vastly from programmatic client
> execution.
Sometimes they do, sometimes they don't. curl and libcurl offer users to make
those distinctions rather than us doing them for them.
Browser-like automation is a pretty signification chunk of curl use cases.
> As for c-ares: requiring a specific asynchronous resolver to process HTTPS
> resource records is an implementation bottleneck, not a validation of its
> design.
I must have missed all your pull-requests and work into improve curl's HTTPS
record resolving without using an external library.
> A user-developer choosing to link that dependency is simply inheriting
> structural complexity.
Linking with libcurl is already "inheriting significant structural
complexity". The key is probably to provide value that is worth more than the
complexity it contains/hides.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-07-30