> Many thanks for your efforts!
thanks for providing the basis for the effort.

> > o) added a new function named curl_formadd that gets the name and the
> > value supplied by the user instead of trying to parse the input string
> > (like in curl_formparse)
>
> I like that. The fact you need to create formatted strings to pass to the
> curl_formparse() function was never really nice. However, your new function
> doesn't support the same set of features that curl_formparse(), which I think
> it should (as then we could make formparse deprecated). Like reading the
> contents off a file or setting content-type etc.

well actually one problem i was solving with my new function was that i
wanted to transfer xml data which was interpreted as a file name (not that
sensible to my data). generally i fully agree with you that one single
function for what is now done by curl_formparse/add/store would be best.

so i would suggest to start the discussion about the new function right
now: it should

o) provide the functionalitye of curl_formparse
while:
o) providing ways of transferring data containing null characters (what
curl_formstore is capable of)
o) allow users to state that their input does not need to be interpreted
o) allow users to state that their buffer needs not be copied (here i am
not sure whether it makes sense to have this option for the name too or
just for the value).

that would give something like:
curl_formadd (const char * name, const char * value, bool copy_value, bool
interpret_value, bool use_length, long value_length, struct HttpPost **
firstitem, struct HttpPost ** lastitem)

perhaps you have a better idea but for me personally i would rather
provide two calls than this overloaded one. one simple one for the most
common case that itself uses the more complicated one. but if you feel the
complicated version is enough (or you find a better way of formulating the
options) that is fine with me. if you like i can send you some
implementation for the function when we agree on the parameters.

> > o) added a Curl_FastFormReader function that tries to fill the given
> > buffer as much as possible instead of just trying to write one line as
> > Curl_FormReader does
> >
> > o) http.c does set fread to Curl_FastFormReader in case the new
> > CURLOPT_HTTPPOST_FASTFORMREADER option is set instead of setting it to
> > Curl_FormReader
>
> Well, can you see any point in keeping the old 'Curl_FormReader' function?
> I really can't see any point with adding this extra option and complexity.

well there is one point: my patch itself does use the old function for
providing the first line of the post "data" containing the mime boundary
string that actually is part of the http header. of course that line could
be obtained easily with another internal function.

to put it in a nutshell it would be fine with me but i am not 100% sure
about possible consequences of changing the default behaviour.

> > o) added a 100-continue handshake for the form/data HTTP POST controlled
> > bye the new CURLOPT_HTTPPOST_USECONTINUE option. this means that http.c
> > adds the new Expect: 100-continue field to the header and already writes
> > the Content-Type: header field plus the end of the header so that
> > transfer.c is able to read the answer before doing the actual transfer.
> > [this change was inspired by the behaviour of w3c-libwww and greatly
> > reduces the delay of single post operations in a lan environment.]
>
> Great addition. I'm not really sure we need that option though. What would be
> the downside of _always_ sending that header when doing POST operations? (It
> should still be able to get disabled with the regular disable-header
> functionality.)

well there are no downsides i can see. it would even be possible to not
allow disabling it (it cannot be disabled with libwww and that seems to
cause no problems). but if it can be disabled one needs to remember the
fact internally to prevent transfer.c from expecting the answer.

i would certainly be happy with this solution too.

> > o) curl_formstore function that gets the name and the value supplied by
> > the user instead of trying to parse the input string (like in
> > curl_formparse). the difference to curl_formadd is that the value is not
> > copied and need not be null terminated => it is possible to post data
> > that does contain null characters with curl_formstore! for simplicity
> > reasons the user has to provide the buffer length and needs to guarantee
> > the existence of the value buffer until curl_easy_cleanup is called.
>
> I like having that capability. Do you think it would be possible to make
> those two into one single function with some extra option argument
> controlling the extra alloc? Having two nearly identical functions makes
> things confusing and error prone.

see the discussion with curl_formadd

> I feel that the interfaces to the new suggested function(s) could be
> discussed a bit more.

good point. hoping for your suggestions to my answer.

bye,
 georg

_______________________________________________
Curl-library mailing list
http://curl.haxx.se/libcurl/
Received on 2001-08-05