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: Luke Palmer via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 31 May 2025 14:28:23 -0400
Thanks for thinking about it.
I'm sure I don't understand all of the nuance here, but in my simple
testing if I disable libcurl's assumption that multiplexed connections have
persistent authentication, everything appears to work. Might it be as
simple as adding a configuration option?
On Sat, May 31, 2025, 11:59 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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
>
Date: Sat, 31 May 2025 14:28:23 -0400
Thanks for thinking about it.
I'm sure I don't understand all of the nuance here, but in my simple
testing if I disable libcurl's assumption that multiplexed connections have
persistent authentication, everything appears to work. Might it be as
simple as adding a configuration option?
On Sat, May 31, 2025, 11:59 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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