Is it safe to call `curl_global_init` before main()?

[curl . greatwolf]

Just a quick question and the title pretty much covers it.

Is it okay to call `curl_global_init` and `curl_global_cleanup` before and
after main() respectively?

What I'd like to be able to do is perform the curl global state init using
C++ class ctor/dtor and static global variables. eg.

class curl_startup_init
{
  curl_startup_init() { curl_global_init(CURL_GLOBAL_ALL); }
  ~curl_startup_init() { curl_global_cleanup(); }
  static curl_startup_init _C;
};
curl_startup_init curl_startup_init::_C;

I want to move curl's global init outside of main into a different
translation unit to
better contain related code.

Now I didn't see much mention about init'ing curl in this fashion, only
that the doc states
`curl_global_init` needs to called prior to creating a curl handle and
invoking the other functions.
It would be great to get some clarification on whether the above idea is
safe to do.

Thanks

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

Re: curl can not stop sending after it received FIN

[Isaac Boukris via curl-library]

On Apr 12, 2017 8:12 PM, "Gisle Vanem via curl-library" <
curl-library@cool.haxx.se> wrote:

Tanyaofeng wrote:

4.We found an issue:
>
> The file server was shut down during sending  file data, the curl can’t
> stop sending data after it received FIN from
> Http Proxy Server until file data was sent finished.
>

If this was a serious issue, it would have been fixed
years ago. Use netstat (or Process Explorer etc.) and you probably see
curl's socket is in CLOSE_WAIT state.

Read here on the subject of a "half-open TCP connection":
  https://superuser.com/questions/298919/what-is-tcp-half-
open-connection-and-tcp-half-closed-connection


I was about to make a similar comment, using HTTP 1.0 example (where
sometimes the client closes it write end side after sending the request),
but here it is the server that is closing its end so although it's
perfectly valid from TCP perspectives, perhaps it doesn't make much sense
for HTTP to continue sending the request if the server could not reply.

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

Re: Multipart POSTs with large bodies

[Reese Grimsley via curl-library]

Hopefully this helps clear up what I am trying to ask, here is an excerpt
of the documentation I am referring to:  "This event should be sent to AVS
as a multipart message: the first part a JSON-formatted object, the second
part binary audio captured by the microphone. We encourage streaming
(chunking) captured audio to the Alexa Voice Service to reduce latency; the
stream should contain 10ms of captured audio per chunk (320 bytes)".

I am trying to get a member on the forums to clear up the format for the
input audio, but the documentation just asks for a binary audio attachment
as the second part, so I would guess that the contents could either be a
file containing the data (e.g. just a txt file of integers) or an array of
that data.  Considering it now, the formadd() should not be difficult to
set up, so I suppose that answers my question there.

So if I wish to stream the audio as stated above, should I try to use
CURLFORM_STREAM with a callback function?  If I understand it right, I
would need to setup a callback function, and use the file to upload as the
parameter for CURLFORM_STREAM and its name for CURLFORM_FILENAME in
formadd, as well as setup the CURLOPT_READFUNCTION to use said callback.
Is the size of the buffer handled automatically by curl, or is there a way
to define it?  Thank you.




On Tue, Apr 11, 2017 at 5:50 PM, Daniel Stenberg  wrote:

> On Tue, 11 Apr 2017, Reese Grimsley via curl-library wrote:
>
> I need to send audio data in the second part of a multi-part POST over
>> HTTP2, in which the data should be broken into "frames" of 320 bytes each.
>> I am using the multi API, and have it set so that this connection is
>> multiplexed with a few others.  I am wondering if libcurl by default sends
>> all data for the entire POST at one time, or if anything is broken up into
>> smaller packets.
>>
>
> Well, it sends it all, but of course it sends the whole thing in a series
> of "smaller packets".
>
> The documentation of the recipient suggests that the audio data is just
>> going to be a stream encoded binary data, so I am led to believe that I am
>> not uploading a file, just the set of data.
>>
>
> Is there a difference? A file is just data with a label on it, stored in a
> file system.
>
> Is this sort of operation supported by formadd() and HTTPPOST?
>>
>
> I don't think I understand what you mean. You can create a multipart
> formpost with curl_formadd() and such a formpost can be sent by libcurl...
> If you can clarify exactly what you need or want the formposts part to
> contain or look like, I can help you do the right formadd.
>
> Otherwise I will need to set up the POST field, and use the
>> POSTFIELDSIZE_LARGE option, correct?
>>
>
> If you rather construct the request body yourself, yes.
>
> The data to upload will most likely be in the range of 100kB to 1MB.  My
>> main question is how to send a ensure that a POST message is sent piece by
>> piece.
>>
>
> It does (without getting into the exact specifics since I believe you want
> the simplified answer here), but you don't have to care about that as it
> doesn't matter for an application. It's HTTP and TCP after all and libcurl
> will send the data you ask it to send. libcurl can't send "all data at
> once". Data is sent and delivered one bit at a time over the wire.
>
> --
>
>  / daniel.haxx.se
>
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: curl can not stop sending after it received FIN

[Gisle Vanem via curl-library]

Tanyaofeng wrote:


4.We found an issue:

The file server was shut down during sending  file data, the curl can’t stop 
sending data after it received FIN from
Http Proxy Server until file data was sent finished.


If this was a serious issue, it would have been fixed
years ago. Use netstat (or Process Explorer etc.) and you probably see
curl's socket is in CLOSE_WAIT state.

Read here on the subject of a "half-open TCP connection":
  
https://superuser.com/questions/298919/what-is-tcp-half-open-connection-and-tcp-half-closed-connection

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