curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Improving form post API

From: Colin Hogben <curl_at_pythontech.co.uk>
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.html
Received on 2017-06-23