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: libcurl and nginx persistent auth behavior
- 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: Sat, 31 May 2025 17:59:01 +0200 (CEST)
On Sat, 31 May 2025, Luke Palmer via curl-library wrote:
> To put this another way, libcurl assumes persistent authentication is
> present when multiplexing, and nginx does not natively implement persistent
> authentication at all.
Thinking about it, I suspect nginx is right on this. Since different streams
can access different resources and are mostly independent of each other, it
does not seem proper to assume they are automatically authenticated just
because they share a connection.
Unfortunately, Negotiate authentication is a horrible mess when it comes to
specification and interoperability so there is simply no good way to come to a
definite conclusion.
The most sensible for servers would probably be to refuse HTTP/2 for Negotiate
the same way they refuse NTLM for HTTP/2, but we're not in the position to
make such demands now. We have to work with what exists.
> This seems tricky to get right, but it's also a shame to have the most
> popular client not be compatible with the most popular server.
Since this is an entirely new logic flow and requirement for HTTP auth and
only for HTTP/2 and HTTP/3, it is going to require some fiddling to get right
I'm sure.
Date: Sat, 31 May 2025 17:59:01 +0200 (CEST)
On Sat, 31 May 2025, Luke Palmer via curl-library wrote:
> To put this another way, libcurl assumes persistent authentication is
> present when multiplexing, and nginx does not natively implement persistent
> authentication at all.
Thinking about it, I suspect nginx is right on this. Since different streams
can access different resources and are mostly independent of each other, it
does not seem proper to assume they are automatically authenticated just
because they share a connection.
Unfortunately, Negotiate authentication is a horrible mess when it comes to
specification and interoperability so there is simply no good way to come to a
definite conclusion.
The most sensible for servers would probably be to refuse HTTP/2 for Negotiate
the same way they refuse NTLM for HTTP/2, but we're not in the position to
make such demands now. We have to work with what exists.
> This seems tricky to get right, but it's also a shame to have the most
> popular client not be compatible with the most popular server.
Since this is an entirely new logic flow and requirement for HTTP auth and
only for HTTP/2 and HTTP/3, it is going to require some fiddling to get right
I'm sure.
-- / 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 2025-05-31