On Wed, 16 May 2012, Joe Mason wrote:

>> 2. When the auth type is CURLAUTH_TYPE_PROXY, the URL field still
>> contains the destination server's URL. But what I really want to
>> know is the proxy's URL, since that is where the authentication
>> credentials are going (other callers might _also_ want to see the
>> actual destination URL, but git does not care in this case).
>
> Also a good catch. But is the url really helpful for proxy auth? First of
> all the proxy address and port isn't really a url, just an address, and
> second it doesn't change due to redirects like the url does. So presumably
> whoever set the proxy address still knows what it is.

As I've understood the problem, an application doesn't necesarily know which
proxy it uses before-hand! If you allow the user to specify it somehow in an
argument or config file the program have to make a rather complicated parsing
to extract the info, but if the proxy information is passed in as an
environment variable the application doesn't necessarily know about it at all
until libcurl detects it. Or it needs to re-implement libcurls environment
variable logic to catch the correct proxy to figure it out. Complicated
alternatives that would be much easier solved if libcurl told the app about
what it figured out.

> Would it be ok for the url to be NULL for CURLAUTH_TYPE_PROXY? (I ask this
> mainly because I'm not sure where to look up the proxy address from when
> filling in the info struct, but also partly because it feels a bit impure to
> be putting the address into "url" when it's not actually a url.)

Right. I think we should better leave the URL as the URL all the time and
rather provide proxy information separately for when a proxy is used.

>> The simplest thing for me would be if CURL called an auth callback
>> (either a separate one, or the same one with an extra flag) to say
>> "yes, I made a successful request to URL X with username Y and
>> password Z".

> Well, curl knows what type of auth it ended up sending, so in theory it can
> call the callback with that info when it succeeds. This would be a good
> thing to put into the library because the embedder doesn't have that info
> easily. I don't know exactly what to change in curl to make this happen off
> the top of my head, though, so it might not be trivial. And I don't have a
> lot of time in my schedule to look into it.

I can see how we can do this, but I can also see how it is slightly
independent of this auth callback - at least in this first step - so I think
we can move on while keeping that idea in the back of our heads and work more
on that later.

> How about adding a bool "succeeded" parameter to the info struct, and just
> leaving it as false for now? Someone else can implement the true case in a
> followup.

Hm, yes that's subtle but should suffice for that use case...

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html