On Fri, 1 Apr 2005, John Chamberlain wrote:

So what's wrong with keeping libcurl talk on the libcurl list?

> The header function capability does not seem to pass a void pointer the way
> the content callback does.

It does. Set the pointer with CURLOPT_WRITEHEADER.

> 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.

Why is doing strncasemp("blabla:", ptr, 7) harder than
sGetHeaderField("blabla:") ?

Such a function you suggest would force libcurl to somehow keep a copy around
of all incoming headers, which I think would be a bad idea.

> It seems logical to me that one (1) the CURL* pointer should be passed to
> the content callback in addition to the user pointer

I agree with that, and all new callbacks we add to the library does this. But
I don't think it is important enough to kill backwards compatibility and
introduce it for this callback.

> and (2) the programmer should be able to have a function like:
>
> char* sGetHeaderField( CURL* request, char* sNonCaseSensitiveFieldName );

I disagree with that. As explained above.

--
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html