curl-library
Re: reworked my patch and used the current cvs as the basis
Date: Tue, 28 Aug 2001 10:52:57 +0200 (MET DST)
On Mon, 27 Aug 2001, Georg Huettenegger wrote:
> i have now added some code to transfer.c to handle this 417 failure. but
> i would suggest you take a closer look whether this is what we want to
> achieve (but as far as i see it the code will either prevent data to be
> sent or stop the sending activities).
Many thanks for all the work. I'm applying your fixes right now.
I think I was a bit stupid when I saw that particular error 417. Aren't we
supposed to stop sending if we get _any_ error code? I mean the Expect:
100-continue says to the server that we want to 100-code to continue. If we
get it, fine, we go ahead. If we time-out, sure, we go ahead. But if we get
an error, any error, I don't think we should continue posting...
This is not a big issue, I'm just trying to figure out the correct behaviour
of a HTTP 1.1 compliant client. I need to study the RFCs some more.
> i have now added CURLFORM_NAMELENGTH and CURLFORM_PTRNAME and made the
> function as flexible as seems possible to me. the only assumption is that
> everything that belongs to one file comes before the parts of the second
> file.
I studied your examples in the source header of lib/formdata.c and the first
one looks like:
curl_formadd (&post, &last, CURLFORM_COPYNAME, "name",
CURLFORM_COPYCONTENTS, "value");
Now, how would you know when this list of arguments ends? I mean, if I'd
append the content lenth too, like in:
curl_formadd (&post, &last, CURLFORM_COPYNAME, "name",
CURLFORM_COPYCONTENTS, "value",
CURLFORM_CONTENTSLENGTH, 5);
This is one pair extra...
Can you explain how the function can be called without CURLFORM_END as the
last argument and still work as discussed? I believe this is just an issue
regarding the comments in the source file, as your man page doesn't have any
of these examples!
-- Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/Received on 2001-08-28