On Fri, Oct 24, 2008 at 12:41:58AM +0200, Josef Wolf wrote:
> On Thu, Oct 23, 2008 at 10:19:27PM +0200, Daniel Stenberg wrote:
> > 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?

AFAICS, there's indeed already existing code to handle that. I'll come
back to that below.

But first, I'd like to express a please. We all know Fred Brook's words:

   Show me your code and conceal your data structures, and I shall
   continue to be mystified. Show me your data structures, and I won't
   usually need your code; it'll be obvious.

In this spirit, it would be a big win if curl's INTERNALS paper would
give a _rough_ overview of the used data structures. It don't need to
be much. Just a couple of lines. Something like

   foo # the root of all evil, lives from startup till dies
   foo->bar # hell starts here.
   foo->bar.baz # created by argl, filled by brr, lives till married

Having said that, I'd like to emphasize that I am absolutely clueless
about libcurl internals. Thus, there's a high probability for the
remainder of this mail being complete nonsense.
So please, if there's anything wrong with my writing, please try to
help me clarifying my misconceptions. :)

Now back to the topic.

At first glance it looks like the functionality I am talking about
could be placed in Curl_http_auth_act(). I guess the two clauses
that handle 401/407 could be extended to retrieve the credentials.
So there's only little change needed to implement the credential
callback: just add a new option to specify the callback
(CURLOPT_CREDENTIALS_CALLBACK or something) and call it from
Curl_http_auth_act().

But on a second glance, it looks to me like some code and data structures
could use some refactoring to improve readability. Please don't get
offended, I am not going to criticize. Chances are that it is hard for
me to read because I am not familiar with the code and data structures. :-)

BTW: What is perhepsrewind() good for? Are there limitation in POST/PUT
     that require reconnect?

BTW1: While glancing through the code, I stumbled over

        /* clear all string pointers first */
        memset(dst->set.str, 0, STRING_LAST * sizeof(char *));

      in url.c:Curl_dupset(). This is not guaranteed to work by the
      language (see subclause 2 in http://c-faq.com/null/varieties.html).
      I'd suggest to change this to

        /* clear all string pointers first */
         for (n=0; n<STRING_LAST; n++) {
           dst->set.str[n] = NULL;
         }

      or something.

        find -name '*.[ch]' | xargs grep memset

      reveals some more candidates.
Received on 2008-10-25