The header function capability does not seem to pass a void pointer the
way the content callback does. This seems to prevent connecting the
content callback with the header callback. For example, I need to decide
how to process an HTTP get based on information in the header. If the
header info is going to one call back and the content to a different one
then there is no way to connect the two. Using global variables and
stuff like that is obviously not advisable for concurrency and other
reasons.

It would seem that the only way to get the header info then is to use
the CURLOPT_HEADER option to get the header written to the stream. That
way the content callback will get it and can parse it.

For future reference, however, it would obviously be nice to have a way
to get the header fields without having to parse them yourself. For
example, I have an HTTP code base in Java I use which has a function
sGetHeaderField( sFieldName ), so I just pass the non-case-sensitive
name of the field and get the string with its content back. It seems
logical to me that one (1) the CURL* pointer should be passed to the
content callback in addition to the user pointer, and (2) the programmer
should be able to have a function like:

char* sGetHeaderField( CURL* request, char* sNonCaseSensitiveFieldName );

That returns any header (or null if it is not found).

-- John C.

Daniel Stenberg wrote:

> On Thu, 31 Mar 2005, John Chamberlain wrote:
>
> (consider the curl-library mailing list in the future for libcurl
> issues, I cc'ed this reply over there now)
>
>> Hello, using the "easy" interface how does one get the
>> Content-Description header field sent by the server?
>>
>> For that matter how are other optional headers discovered?
>
>
> Both these questions have the same answer:
>
>
> http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTHEADERFUNCTION
>
> If you end up writing a small test app for it, I would appreciate if
> you posted it to us so that we can add it as an example source!
>
Received on 2005-04-01