On Tue, 7 Aug 2001, Georg Huettenegger wrote:

[ curl_formadd ]

> i think your proposal makes more sense than mine for libcurl (as my
> approach is somewhat more c++ oriented, but in true c++ i would have
> added default values for many variables).
>
> i'd say i try to formulate an implemenation until the end of the week
> (today and tomorrow i am too busy to start).

That would certainly be cool!

> so i would say we make the rename the FastFormReader to FormReader and
> insert a new internally used function for getting the first line.

I agree, let's do that.

> > So when posting to a HTTP 1.0 server with the Expect header, we will *have
> > to* wait for a while for a possible 100-code to return, and first when we've
> > decided that the response isn't coming we can continue to do the actual POST.
>
> then i would suggest making 100-continue the default and adding some
> option to allow disabling it (or use the disable-header functionality you
> already mentioned).

Hm, assuming that the vast majority of all web servers are HTTP 1.1, I figure
it is safe to default to have 100-continue enabled. I mean, we do need to
support time-outing the waiting anyway so the result would only be that 1.0
web servers that doesn't understand that header will get the POST slightly
slower. There's a minor risk that we get more 417-errors ("A server that does
not understand or is unable to comply with any of the expectation values in
the Expect field of a request MUST respond with appropriate error status.")

On the other hand, we don't do the Expect: header today and this works with
all servers, it only takes a little extra network load and wasted time to
figure out if we weren't allowed to POST to a site.

I think I lean towards disabling 100-continue by default.

> as to the code already handling the 100 continue in transfer => i must
> admit i did not see that piece of code. once again i will take a look at
> it later on this week and try to provide a new patch.

There might be reasons to make modifications to this (I haven't really
thought trough all details) but web servers MAY send 100-codes even when
they're not asked for, so libcurl already supports them.

There might also be reason to look into how we can support the "101 Switching
Protocols" code while we're at it (as a result of using the Upgrade: header),
but maybe we should get the 100 code work first.

> the only thing left is to decide whether 100-continue should be the
> default and how to disable or enable it.

Whatever we decide, I like having the generic way of disabling headers
working. It let's the programmer disable whatever header (s)he desires with a
common interface. Check out lib/http.c how checkheaders() is used to only add
headers unless they were custom added/replaced/deleted.

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