Re: HTTPS-RR and ECH

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.html