On Thu, Oct 23, 2008 at 10:19:27PM +0200, Daniel Stenberg wrote:

Thanks for the answer, Daniel!

> On Wed, 22 Oct 2008, Josef Wolf wrote:
> > int curl_get_credentials (char *user, char *passwd, /* return values */
> > const char *realm, const char *url,
> > int isproxy)
>
> You'd also want a custom user pointer (for passing on local contexts) and

Yes.

> possibly a CURL *.

The url pointer would be redundant, then? I guess the URL can be deduced
from the handle contents?

> I wonder if a auth type (Basic, Digest, NTLM etc) would
> be wanted as well.

What would this be used for?

> >maybe with additional parameters telling the size of the buffers for the
> >returned values.
>
> That too, otherwise it's like begging for overflows.

For sure.

> >2. I expect the callback method to avoid code duplication on three levels:
>
> Yes, it just might and those are some good reasons. Although most of it
> could be solved without adding a callback if just the right info is
> returned or is readable after the return.
>
> But in my experience applications in general don't have general 40[17]
> response handlers. Most apps already know when they need auth and they
> already set the requested type(s) and they provide name and password. I
> think that's the primary reason why not more people have asked for support
> of something like this.

Yes, but providing user+passwd in advance is only possible if the
application knows that the remote side will ask for it.

> > c. I guess even some code from CURLOPT_FOLLOWLOCATION could be
> > reused.
> > After all, the overall handling for both situations is
> > identical: repeat the request with slightly modified parameters.
> > The only difference is that in case of 401/407, the additional
> > parameters need to be retrieved from the application instead
> > of the response header.
> > I don't see the point in handling one situation within the
> > library but requiring the application to handle the other
> > (almost identical) situation by itself.
>
> libcurl already has lots of support and code for 401/407 handling (and yes
> it is similar to the redirect following in large parts) so that's now what
> would be needed to get introduced.

Huh? So libcurl already tries to repeat the request with different
credentials? This sounds like I have missed something important in
the documentation? Can you please drop some hints about how 401/407
is handled right now?

> In summary: I'm not entirely against the idea. It'll of course take a
> chunk of code to get this working nicely.

So I will dive into the lib and see whether I can get a better
understanding about the details. Maybe you have some hints for me
where to start digging?

Thanks!
Received on 2008-10-24