curl / Mailing Lists / curl-users / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.


From: Daniel Stenberg via curl-users <>
Date: Fri, 26 Mar 2021 18:14:24 +0100 (CET)

On Fri, 26 Mar 2021, kent williams via curl-users wrote:

First: there's a dedicated mailing list for libcurl that's usually more
suitable for libcurl topics: curl-library

> So, naturally, I get a request to allow both at once.  The catch is that if
> you turn on CURLOPT_HEADER, the headers always go into the data sent to the

If you want them separate, why force the headers into the same callback?

> I have a solution but it feels kind of wonky. The CURLOPT_WRITEFUNCTION
> buffers all the data it gets, and checks it for "\r\n\r\n"  Once it sees
> that, it knows the headers are done, and writes the rest of the data to file.

... or you would just use *separate* callbacks as libcurl already split the
headers from the body for you?

> I didn't find a CURLOPT that tells libcurl "don't send headers to the

That's the default behavior. You changed it by setting CURLOPT_HEADER to 1.
You can switch it off again by setting CURLOPT_HEADER to 0.

> I also didn't see any guarantee that the CURLOPT_WRITEFUNCTION can depend on
> its data being null-terminated strings, a line at a time, though that
> certainly is what I observed.

I think this quote from the man page is pretty clear on this topic:

  The data passed to this function will not be null-terminated!

And also: the data provided in the write callback is not "strings" at all. It
is binary data that might be text at times.

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features

Received on 2021-03-26