curl-library
Re: Improving form post API
Date: Fri, 23 Jun 2017 11:10:50 +0100
On 22/06/17 22:44, Daniel Stenberg wrote:
> I took the liberty of updating the API suggestion in the wiki with some
> of the stuff I came up with in this response:
>
> https://github.com/curl/curl/wiki/formpost-API-redesigned
in which:
> To send "file", use curl_form_set_file instead of curl_form_set_data
>
> curl_form_set_name(part, "upload", -1);
> curl_form_set_file(part, "/tmp/upload.tar.gz", 0, NULL);
>
> To instead "upload" the file from a local buffer and setting a made
> up file name for it:
>
> curl_form_set_name(part, "upload", -1);
> curl_form_set_file(part, buffer, buflen, "made-up-name");
Overloading data-from-file and data-from-buffer in this way, using the
length argument as the discriminator, seems troublesome when you want to
upload an zero-length datum from a buffer.
I think that there are two pretty much orthogonal issues here: whether
the form part is file-upload-like as seen by the server; and where the
data comes from within libcurl.
Perhaps we should have e.g.
curl_form_set_file_info(part, filename, content_type);
which populates the filename= attribute of Content-Disposition header
and the Content-Type header;
then
curl_form_set_file_data(part, filename);
for a real local file, or just use curl_form_set_data if using a buffer.
Admittedly there is a little duplication of information in the case
where the filename attribute is the basename of the local file.
At the risk of bloat, we might want a READFUNCTION/READDATA style
variant for the part data too.
-- Colin Hogben ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2017-06-23