Feature Requests item #1949716, was opened at 2008-04-23 15:54
Message generated for change (Settings changed) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=1949716&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Zmey (zmey_)
Assigned to: Daniel Stenberg (bagder)
Summary: Reaching under the hood.

Initial Comment:
Hello,

Libcurl defines and uses several handy functions internally:

Curl_md5it() - computes an MD5 hash of a string;

Curl_base64_encode(), Curl_base64_decode() - encode and decode data in Base64 encoding.

These are just some (those which I used); other such functions may exist.

It would be great if these functions were made public and documented like it is already done with curl_easy_escape(). It is not logical to link to an external library for, say, computing MD5 hash when you know that this functionality is already in libcurl.

Note that existing Curl_* functions are not functional/robust enough to be exported:

Curl_base64_decode(): output is garbled if the input contains any non-base64 characters (like newlines and such). Robust implementations must skip such characters.

Curl_md5it() is string-oriented and cannot be used to hash binary data.

Other feature that (I hope) could be easily implemented, yet add to libcurl's flexibility: cooked connect, send, receive, poll, and disconnect functions. By "cooked" I mean the following:

'connect' is done using usual curl_easy_setopt()/curl_easy_perform(), so the application does not need to hassle with proxy/SSL negotiations and all such. The difference from regular, say, http transfer is that the "performance" finishes after connecting to the server, not after the protocol session is complete. After the connection is established, you could use the handle in subsequent send/receive operations.

'send' and 'receive' (I am dreaming here) work with curl handles, not sockets. Thus, it will be easy to write applications implementing custom network protocols, yet capable of working though proxies and SSL connections.

I guess that this (or similar) functionality is already in the guts of libcurl, but is not usable from outside. Wouldn't it be great if there were some public interface to send/receive raw data?

Rationale:

Currently we are forced to use predefined protocols (known by libcurl). If you want something non-standard, you should either implement it yourself from scratch, or modify libcurl.

(Yes, you can send and receive arbitrary data from callback functions. Isn't it ugly? I tried to write a simple libcurl application that talks to a telnet server and... I couldn't).

----------------------------------------------------------------------

Comment By: Zmey (zmey_)
Date: 2008-04-24 09:31

Message:
Logged In: YES
user_id=1835005
Originator: YES

Ok, I agree that mailing list is a better place for such a discussion
(though I didn't find libcurl-devel mailing list; will post to
curl-library).

As for your concerns about fixing the movable: I don't think that
interfaces for computing MD5 sum or encoding/decoding Base64 will ever
change.

Anyway, I feel I have put too much into one post; I will split it into two
posts to the mailing list.

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2008-04-23 19:30

Message:
Logged In: YES
user_id=236775
Originator: NO

curl already does this for some functions--the curlx functions, although
they aren't actually exported by the library. See
http://cool.haxx.se/cvs.cgi/*checkout*/curl/lib/README.curlx?rev=HEAD&content-type=text/plain
As you admit, it can take some effort to make these functions broadly
usable and safe for apps to use, with no real benefit to libcurl itself.
The other down side is that the API then becomes fixed which can conflict
with changing requirements within libcurl.

I suggest bringing your suggestion to the libcurl-devel mailing list where
people can publicly discuss the merits.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=1949716&group_id=976
Received on 2008-12-26