On 05.07.2012 19:27, Daniel Stenberg wrote:
>> Oh, no, I do want to receive the server's reply (or at least the HTTP
>> code), I just don't want curl output the data on the console (stdout
>> or stderr). The server's reply is only a single line, so there's no
>> harm in reading that from the network.
> But shouldn't you then use the write callback to receive the data?

Why use a callback function when I don't need the reply. I just want
libcurl to discard the data.

>> If there's currently no simple way to do that, may I propose that make
>> that possible? E.g. by calling the write function only if it is set to
>> a custom func or the file handle being not NULL.
> Sorry, I must be missing something here. What would be the point of that?

It seems that I created some confusion. Sorry for that.
It's really not a big deal. As I wrote: All I want to do is to let
libcurl perform a HTTP POST, discard the server's reply (the data, not
the response code of course, which I get with CURLINFO_RESPONSE_CODE). I
just thought that it might be a good idea to support that inside of
libcurl. So instead of using a dummy callback function like here:

size_t curl_devnull(char *ptr, size_t size, size_t nmemb, void *userdata) {
        return size * nmemb;
}

int main
{
...

curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, curl_devnull);

one could just do
int main
{
...

curl_easy_setopt(curl, CURLOPT_WRITEDATA, NULL);

I admint that this might look a litte posh or lazy, but I think it's a
(small) improvement in the API. As there is no valid use for using a
NULL file handle with the default write function, it's also compatible
with the current behaviour. And preventing a segfault by not letting
fwrite use a NULL file handle could also be a good thing.

So, it would be nice if you would accept my change. But rejecting it
would also not give me sleepless nights :)

Rergards,
Jakob
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-07-08