Returning redirection URLs (was: SSL problem + request for enhancement)
Date: Mon, 27 Jan 2003 15:17:40 +0200
I am still none the wiser to what you think on this issue, though. Here are the
known facts so far:
1) The info could be sent to the DEBUGFUNCTION along with other debug info, so
that the user has control over where the redirections take him/her.
2) The info could be requested at the end of the transfer through a special
We have also agreed that (1) is easier to implement in libcurl than (2).
What we have to decide is which is more useful and user-friendly. Maybe we need
to hear from other libcurl developer on this issue.
BTW, I guess this is a generic problem for exposing info not currently exposed
by libcurl. If we find a generic solution then it would be easier for the future
to expose other info. Looking at the "curl_infotype" used in the DEBUGFUNCTION,
I don't think this function was designed to support returning such info.
Thinking along these lines maybe we can add (I know I will be crucified) another
callback function that returns such info during the transfer. Also would be
present extra setopt options to turn on and off certain types of info.
----- Original Message -----
From: "Daniel Stenberg" <daniel_at_haxx.se>
To: "libcurl Mailing list" <curl-library_at_lists.sourceforge.net>
Sent: Monday, January 27, 2003 12:41 PM
Subject: Re: SSL problem + request for enhancement
> On Wed, 22 Jan 2003, Ufuk Kayserilioglu wrote:
> > I am not very familiar with what the DEBUGFUNCTION supplies because I never
> > had to use it. However, if it is the same info output by the verbose mode
> > then maybe it is too much over head if you want just to be *informed* of
> > the URLs that are visited. I was thinking more along the lines of a
> > curl_easy_getinfo() option which returns a linked list of visited URLs. The
> > way I see it this information could very well be retrieved after the fetch
> > rather than during it.
> Ah, that might indeed be a fine way to do it too.
> > For me both ways are OK and not much problem to implement on my app side.
> > However, I guess the DEBUGFUNCTION way would be easier to code inside
> > libcurl.
> It would! But then again, I guess we should do things the way that causes the
> least effort for the libcurl programmers. We should concentrate on getting a
> useful and friendly API for the libcurl-users.
> Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
Received on 2003-01-27