On Tue, 21 Aug 2001, Georg Huettenegger wrote:

> > 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.
>
> that is true, do you mean i shoudl take a look to achieve these goals
> (did not think about them as i am not that firm when it comes to http
> posting).

I would certainly appriciate it if you did. Just let me know if you can't.
When in doubt on how HTTP posting works, RFC2616 is your friend...

[ curl_formadd() ]

> well i agree with most of your points but i still do not see the benefit
> of allowing unordered input.

There isn't much benefit seen from our perspective, no. On the contrary,
supporting unordered arguments probably gives us more headache.

The benefit will be visible when users of the library will start feeding the
arguments in seemlingly random order (and unless it works, they will start
mailing questions to us)! I also think that in general, when a function
accepts a list of options such as the new curl_formadd(), it is a good habit
to accept unordered arguments as far as possible.

The general libcurl user will insert the arguments in the order that (s)he
thinks the function supports, which isn't necessarily the same way that we
think the function should be used.

> the code already allows some variants (like having the length before the
> type and vice versa) but there will always be two parts: the part with
> the name and the content part that additionally may consist of multiple
> file parts.

Yes.

> i would propose to add PTRNAME and to allow CONTENTSLENGTH for COPYNAME,
> PTRNAME, and COPYCONTENTS

I would prefer a separate option to set the length of the name field,
NAMELENGTH (or similar), that if set is used for either PTRNAME or COPYNAME.
CONTENTSLENGTH then sets the size of the PTRCONTENS or COPYCONTENTS data.

> as for code reduction i would rather try to put some code into a seperate
> function that to try to handle everything at once. so i would see a
> function that does parse the CONTENTTYPE and CONTENTSLENGTH as a possible
> way of getting maintainable code.

That's a good idea.

> what do you think, should i try to enhance curl_formadd as outlined by
> me?

Would be great!

> will take a look later on this week (also changes from me would propably
> not arrive before sunday/monday).

No worries, I'll keep busy with all those other things that need attention!
:-)

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