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.
Re: Using CURLOPT_WRITEFUNCTION along with CURLOPT_HEADERFUNCTION
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_cool.haxx.se>
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
> CURLOPT_WRITEFUNCTION.
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
> CURLOPT_WRITEFUNCTION."
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.
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-03-26
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
> CURLOPT_WRITEFUNCTION.
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
> CURLOPT_WRITEFUNCTION."
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.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-03-26