Daniel Stenberg wrote:
> There's nothing that stops you from using a DEBUGFUNCTION to receive that
> string.

Thanks, I hadn't previously understood DEBUGFUNCTION but now I do and
have implemented it as you say. A few notes from the experience: I see
little explicit documentation on how to use DEBUGFUNCTION and no code
examples. The curl_easy_setopt page which mentions DEBUGFUNCTION makes
reference to curl_infotype but curl_infotype is not documented (?). I
had to look into the hearders to see what it is.

Also, curl_easy_setopt page says "This function will receive debug
information if CURLOPT_VERBOSE is enabled." but should probably say
something more like "CURLOPT_DEBUGFUNCTION replaces the standard debug
function used when CURLOPT_VERBOSE is in effect with the specified
function". Because it wasn't clear to me that this was instead of
regular verbosity or in addition to it.

Last, is there a documented way to pass control along to the standard
debug function? I.e. in my case I only wanted to change the handling of
one of the infotypes (CURLINFO_HEADER_OUT) and would have liked to pass
all others off to Curl_debug() instead of doing what I did which was to
replicate all the logic of Curl_debug() and modify it for the one case.

> and if you think that is a good idea you can translate URLs as you see fit.

Well ... more precisely, and as noted, I made it an option. So it's not
a matter of whether I think unescaping URLs is a good idea but rather of
when and if the user wants to see them in that form. Very commonly in my
use there's a long calculated value being passed as a query parameter,
and showing it in unescaped form allows it to be cut and pasted into
non-HTTP contexts. Which can be very useful.

Thanks,
M.B.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2003-09-12