cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Differences between the buffer-oriented curl_fromadd() parameters

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 2 Oct 2002 10:15:06 +0200 (MET DST)

On Tue, 1 Oct 2002, Holger Rauch wrote:

> What I'm actually trying to do is that I want to upload a buffer using HTTP
> POST request. Basically, the buffer is similar to what's provided in the
> example section of the man page:
>
> char htmlbuffer[] = "<HTML>test buffer</HTML>";
>
> but it's longer and contains XML instead of HTML data.

If all you want to do is make a normal POST, then curl_formadd() is not the
way to go. This is only used for multipart (RFC1867) formposts.

> > BUFFER sets a name for the buffer upload. This name is what the "filename"
> > will be set to, as this is a "file upload" kind of form.
>
> Why is there another CURLFORM_* option for this purpose? Why can't I just
> CURLFORM_COPYNAME for that? I had the impression CURLFORM_COPYNAME is the
> CURLFORM option used to set field names. Or am I wrong?

You need to understand the differences here. A multipart post are constructed
by a series of parts (hence the multipart name). Each part has a name and a
content (and a content-type etc but let's ignore that for now). But if the
part is a "file upload" part, it also has a file name. So, to make a part of
look like a file upload part to the receiver, all those three data need to
exist in the part.

The COPYNAME and PTRNAME set the name of the part. COPYCONTENTS and
PTRCONTENTS set contents. FILECONTENT is a special one that lets you name a
file instead of content data, and libcurl will get the contents from that
named file instead.

If you don't want to make a file upload, all is fine using those.

> > > curl_formadd(&post, &last,
> > > CURLFORM_COPYNAME, "name",
> > > CURLFORM_COPYCONTENTS, "data",
> > > CURLFORM_END);
> >
> > The only difference here is that this COPYCONTENTS copies the data part too.
>
> Ok. So, in contrast to the example using CURLFORM_PTRCONTENTS, this example
> will contain a field name whose data is contained in a buffer named "data",
> whereas in the example using CURLFORM_PTRCONTENTS, the field data for the
> field named "name" is just the string "data". Right?

Nope. Using these two makes absolutely no practical differecence:

 curl_formadd(&post, &last,
              CURLFORM_COPYNAME, "name",
              CURLFORM_COPYCONTENTS, "data",
              CURLFORM_END);

...compared to...

 curl_formadd(&post, &last,
              CURLFORM_PTRNAME, "name",
              CURLFORM_PTRCONTENTS, "data",
              CURLFORM_END);

They'll both create identical formparts. The only difference is how libcurl
will refer to the data. The COPY* ones make libcurl copy the data and keep
track of it itself, while the PTR* ones make libcurl use the buffer you point
to.

> > > curl_formadd(&post, &last,
> > > CURLFORM_COPYNAME, "name",
> > > CURLFORM_BUFFERPTR, "data",
> > > CURLFORM_END);
> >
> > This makes it a file upload part, as that's what BUFFERPTR implies. I
> > believe this particular use of the function will return an error code, as
> > you haven't provided a BUFFER to name the file in this faked file upload.
>
> Ok. I now understand what's wrong with the example given above.
>
> The reason why all of this seems pretty confusing to me is that different
> CURLFORM_* options are used to set the values of certain field name. Why
> wasn't something like a CURLFORM_COPYNAME/CURLFORM_COPYVALUE pair
> introduced, allowing you to set CURLFORM_COPYNAME to "filename" and
> CURLFORM_COPYVALUE to "blah.txt"? I admit that this would probably not be
> as flexible as the current approach, but (at least in some cases) a bit
> more obvious.

But that is already the general idea behind the naming of these options!
*NAME set the name of the part, *CONTENTS set the contents part. The other
options are mainly there to build file-upload parts, as they need file name
too for example.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-10-02