On Fri, 27 Jul 2001, Georg Huettenegger wrote:

> i have now enhanced the patch (curl-7.8-gh-patch-20010717) i have sent 10
> days ago.

Many thanks for your efforts!

> o) changed some char * to const char * to make the compiler happy
> (although there are quite a number of char * that could be made to const
> char *)

I agree with these.

> 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.

> 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.

> 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.)

> o) when writing is done within transfer.c clear the writesocket so that
> select does not keep waking the select call with the write file descriptor
>
> the last point addresses the same issue as does Tomasz.Lacki suggestion
> of 2001-07-12 to add FD_ZEROs and keepon &= ~KEEP_XXXX; to transfer.c. i
> am not sure whether it must be done for the read file descriptor (won't
> transfer.c will end then anyhow), but i assume that the correct way is to
> make the FD_CLR that is done in my patch.

I already added this fix.

> 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.

> still hoping that my changes are beneficial for the libcurl herself
> (although you might want to further improve my new functionality as it is
> tailored for my needs) and incorporated in the next release.

I intend to use most of it, if not all.

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

-- 
     Daniel Stenberg -- curl dude -- http://curl.haxx.se/
_______________________________________________
Curl-library mailing list
http://curl.haxx.se/libcurl/