On Mon, 20 Aug 2001, Georg Huettenegger wrote:

> after some disucussions with daniel i reworked my patch and took
> curl-7.8.1-pre5 as the basis.

Mighty fine work, Georg! I'm currently applying and fiddling with your
additions.

I intend to commit them to CVS soon so that you can view what minor changes I
did to your patches.

> o) the new default behaviour of the library is to use a 100-continue
> handshake with the webserver. if this is not appropriate disable the
> header (using curl_easy_setopt (CURLOPT_HTTPHEADER)) - this is shown in
> the new sample postit2.c This change affects urldata.h, url.c, http.c,
> and transfer.c (that waits for the 100-continue header before it writes
> anything - if a timeout is encountered it nevertheless writes without
> waiting any further).

This is 99% fine. I can only think of this minor detail we still need to fix:
when we do a POST with the Expect: header present. What if the server returns
"417 Expectation Failed" ? It should make us _not_ send a single byte of the
post stream. And similarly, if we have timed-out waiting for 100 and thus
started to send data, we can still get "417 Expectation Failed" and thus we
should stop sending POST data. Neither of these cases happen right now.

BTW, I just added test case 44 that tests posting without Expect: header,
which seems to work just fine.

> o) added a new function curl_formadd that is intended to supersede
> curl_formparse (and i already changed the documentation to state that
> curl_formparse is deprecated => if that is not agreed i will change it
> back).

I agree with that conclusion and how it is stated in the docs now. I can't
see any point in us maintaining two functions with this similar
functionality.

> it does allow the following: adding simple name/content sections, adding
> single and multiple file sections, adding sections where a pointer to the
> memory is provided (and in case the length is also provided the memory is
> allowed to contain null characters). Everything may have a contenttype.

I like it. I do have some suggestions though, that'll make the function more
robust and less error-prone when used:

 o store all input data in one struct and act on all the data when the
   CURLFORM_END is received, it makes the order of the input totally
   irrelevant and it proably also would make the code smaller. Hm, we still
   need to support multiple CURLFORM_FILE items of course and thus we must
   probly enforce a strict order in which the CURLFORM_FILE must be set
   before CURLFORM_CONTENTTYPE.

 o CURLFORM_COPYCONTENTS should support that we specify the length too,
   and not require strlen() to work. The CURLFORM_CONTENTSLENGTH would work
   the same way for both CURLFORM_COPYCONTENTS and CURLFORM_PTRCONTENTS.

 o The exact same would go for the name, which then could be copied or
   pointed to, which an optional length.

Or am I wrong?

> i would suggest adding my changes into curl-7.9 (or better in the first
> 7.9 pre) and not into 7.8.1 so that my changes can be tested for some
> time.

Feel free to get the lot from CVS now and have a look!

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/