Hello,

2 years after, I think I'll do the work...
There is now a sample with CURLOPT_COPYPOSTFIELDS / CURLOPT_POSTFIELDS / CURLOPT_POSTFIELDSIZE / CURLOPT_POSTFIELDSIZE_LARGE

We can imagine:
CURLOPT_COPYSSLCERTDATA / CURLOPT_SSLCERTDATA / CURLOPT_COPYSSLCERTDATASIZE
CURLOPT_COPYSSLKEYDATA / CURLOPT_SSLKEYDATA / CURLOPT_COPYSSLKEYDATASIZE
CURLOPT_COPYCAINFODATA / CURLOPT_CAINFODATA / CURLOPT_CAINFODATASIZE

Regards
Gilles Vollant

-----Message d'origine-----
De : curl-library [mailto:curl-library-bounces_at_cool.haxx.se] De la part de Daniel Stenberg
Envoyé : mercredi 21 septembre 2016 13:52
À : libcurl development
Objet : RE: Using PKCS12 certificate from memory

On Wed, 21 Sep 2016, Gilles Vollant wrote:

> I tried the "binary" option you suggested, and this not perform well. Only
> the base64 option does the job.

That's crazy talk! Of course you'd need to change some code to make libcurl
handle such a binary input as I suggested could be a cool way to do it. You
can't add support for files provided from memory base64 encoded either without
changing code.

When changing code and providing new features, I think we should go for the
best and most useful approach given the circumstances.

My experience with people asking for support for in-memory objects instead of
external files, is that they usually ask for that because either they A) don't
have a file system at all or B) they don't want to have any external files to
their application or C) they already have that data in their program's memory
anyway.

In exactly none of those cases does it make sense for the program to base64
encode the binary data (which can be huge in some cases) and pass that to
libcurl, only to have libcurl strdup() that data and then decode it to binary
again.

Also, with my suggested approach the code could automatically detect when such
input was given and it would not be possible to confuse with an actual file
name. With base64 encoded input, we'd need to invent a prefix that a file name
couldn't have, so you couldn't even just use a plain base64 encoded area
either.

> Base64 is, pehaps, also more easy for user of libcurl using other langage
> than C or C++ and binding.

libcurl bindings have glue code to make their environments adapt to the
libcurl API and if bindings would want base64 encoded blobs, they can easily
do that. But I doubt they will. For bindings, I would say it makes much more
sense for them to be able to keep such data in their ordinary variables and
pass such a variable on when setting options and then I suspect it is more
likely that the data is actually already there in a plain binary area
somewhere that the binding glue can figure out and pass to libcurl.

> I think the maintainer of curl must choose between a base64 approach, with
> less modification on curl code, or a binary approach, which need
> modification on url.c (by example)

Again, we need to modify source code anyway and there's no existing code that
uses this feature so we should make the new feature as good as possible while
making sure we don't break existing code using these options.

My suggested approach would be a generic
how-to-send-binary-data-to-options-that-accept-file-names, and this option
would then be the first one to use it.

I am the maintainer of curl, but I much rather have us discuss solutions and
come to an agreement we both/all think is good.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html