So since I am going to be using the same host, it will use the same
physical connection, and it will be able to send multiple independent
transfer?\

To piggyback off of this, I am confused on how to format a multipart POST
request. I notice that when I set the content-type to multipart/form-data,
it includes its own (randomly generated?) boundary term. Can this boundary
term by easily changed? My main question though is how to set the fields
that look to be very similar to headers underneath the --"boundary" line,
and then include the actual message data below that. Should these fields
be defined by some setopt function, or are they a part of the message? It
is supposed to look like what I have included in the last few lines of this
message.

Following these "headers" (are they considered headers, or is there a
better terminology?) would be a JSON formatted string of data, followed by
a --boundary-- line. I assume that curl will be putting the boundaries in
as necessary, because I am unsure how I could do it myself if the boundary
term is randomly generated each time I run my program.

--{{BOUNDARY_TERM_HERE}}
Content-Disposition: form-data; name="metadata"
Content-Type: application/json; charset=UTF-8

Thanks,

Reese

On Tue, Apr 4, 2017 at 4:38 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 3 Apr 2017, Reese Grimsley wrote:
>
> The GET request is supposed to open a connection that should time out
>> after 60 minutes or more, but is only there to wait for directives.
>> According to documentation, this connection is to stay open server side and
>> half closed client side for the life of the connection, and it is mentioned
>> that there may be long periods of time where no directives are sent at all.
>>
>
> Well curl has no default timeout for a transfer that just doesn't get any
> data or response so it'll just sit there waiting for something to get sent
> from the server. curl won't half-close its end, but that's not a concern
> since it won't send anything anyway when it is waiting for data fom the
> remote.
>
> This sort of setup generally causes some problems if you're totally silent
> over the connection though since NATs/firewalls will kill off idle
> connections after N minutes. A common way to void that is to set TCP
> keepalive, but some boxes don't consider that to be traffic enough to
> prevent connection close. That's outside of curl though. Just how some
> networks work these days.
>
> It looks like I will need to try to use the multi interface. So just to
>> check if I am understanding this correctly, I could have a number of easy
>> handles under a single multi handle, and use these separate but related (by
>> multi) easy handles to send different requests asynchronously on the same
>> connection?
>>
>
> Not quite. Or maybe.
>
> The multi inteface is for doing many parallel transfers simultaneously. If
> you add N transfers to N different hosts, they will use N connections for
> that.
>
> If you happen to ask for multiple HTTP transfers from the same host, and
> said host supports HTTP/2, you can do several multiplexed transfers over
> the same physical connection. But they're still N independent transfers.
>
> The documentation specifies using the existing connection for sending the
>> GET message to also send a POST message shortly after, as well as pinging
>> the servers on a 5 minute interval.
>>
>
> For each new transfer you inititate with curl, it will check to see if
> there's an existing previously used connection alive that it can reuse for
> the next transfer. So even with the easy interface, when you do a GET you'd
> reuse that same connection for a subsequent POST as long as you reuse the
> easy handle.
>
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> Unsubscribe: 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
Received on 2017-04-04