> > looked at that .. won't work as there are no fields on the end point
> such as name=foo etc.
> >
> > However .. I guess I could just shove the entire datastream to be
> sent into the parameter for CURLOPT_POSTFIELDS. That seems to be what
> you suggest.
>
> If your server doesn't want fields like name=foo, then don't send those
> fields--send what the server expects.

Well, therein lay the seeds of my problems. The people that own the server on the other end don't know what it expects. No really, I am being quite serious. It has taken weeks of phone calls and emails to finally dig into some large corporation and finally get someone to say "we don't know". What they do know is that they inherited software written once upon a time long ago by other people who are long gone, since replaced by other people that also left and forgot to pass on passwords to various things. These people got promoted, moved, changes names are are living under a tree in Bolivia perhaps but the fact is, no one knows. Welcome to my hell. :-)

But there does exist some software binary that I call mystery-part-A and it is able to transmit xml to a server that listens on port 443. Guess what, yep, everything is encrypted also.

So really this is a bit of a process where I have to literally peck away while reading the RFC's on the HTTP protocol and ensure that I see what headers are required as a minimum before sending along a pile of xml.

Thought I was making progress really.

However, I must say, I did not know about those manpages and guess what? I really did print off the entire manpage as well as the curl_setopt manpage ( massive! ) and three hole punched them and sat down to read, all of them. Every bit.

Those are great docs. Well written. I mean really "good stuff"(tm).

> Using CURLOPT_POSTFIELDS is the
> most straightforward way, but if there's a lot of data to send you can use
> a
> callback function instead (such as in post-callback.c).

I was reading about the various callbacks and got as far as the possibility to replace the progress meter. I think it is cool that one needs to set an option to zero in order to enable the progress meter. Really, if one thinks about it, that makes total sense. One should prefer to enable a callback function to capture the progress data as opposed to letting it stay out to stdout. No real world application that lives in front of sql databases and such would spew out data onto stdout, at least not without good reason. So yeah, makes sense to set an option to zero to tell the progress meter to "shut up and be quiet" and provide a callback function to capture the data.

So I am reading all the manual pages I can get my hands on. Really, these are world class docs here.

> From your original
> post, it looks like you'll want to send a non-default Content-Type
> header as well which you'd do with the CURLOPT_HTTPHEADER option.

Bingo. My thinking also. I was getting into the bits about the standard headers that libcurl provides as well as how to override them and provide a new linked list struct with the headers that I want, or need. This is where curl_slist_append will be essential I think.

> > hey .. this is a process of try something, fall over, stand up, ask
> a question, try again, fall over, ask a question .. try something else
> .. fall over .. stand up.
> >
> > So yeah .. I get it.
>
> You can do it that way if you want to, but we've written over 59,000
> words of
> man pages and over 9,000 lines of example programs so you don't have
> to. If you
> feel that there is still something missing after reading that, please
> let us
> know so we can improve it! Lots of people have put a lot of effort
> into writing
> that documentation and example code, so please use it as much as you can.

I am truely digging into the docs. One thought that keeps crossing my mind is "hey, this can also do this and that and heck, this is a real swiss army knife" where everyone knows that a SAK ( Swiss Army Knife ) is a thing that can nearly do anything.

> > also .. in that test example, after this :
> >
> > /* Perform the request, res will get the return code */
> > res = curl_easy_perform(curl);
> >
> > where is the reply from the server ?
> >
> > thrown away ?
>
> By default it gets written to stdout. You can send it to another file
> if
> you want, or process it another way using a write callback function (see
> getinmemory.c for one example).

Yes .. I did jump in before doing enough reading. Truely.

So now I see that I need a few callback functions which, slickly, all seem to reply with size_t type reports about what they are doing for me.

I will be back to post more meaningful questions and will most likely refer to page numbers in the manpages.

Thank you for the pointers ... am reading reading reading right now.

Dennis

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-03-02