On Tue, 16 Jun 2009, Yang Tse wrote:

> Won't this break at least curl's telnet support when used as default setting
> for everything?

No, because telnet doesn't use the upload feature in curl which sets the
non-blocking.

> Besides the different methods of setting a 'socket' to non-blocking which is
> handled in the library with Curl_nonblock(). This introduces a completely
> different portability problem. obviously stdin is not a socket it is a
> 'special' file descriptor.

Oh right. But won't this just cause the function to fail and thus the users on
systems that can't do non-blocking stdin (or pipes) will just have to live
with it blocking? The current approach doesn't have this problem of course
since it is a bit simpler and won't even attempt to work on windows (which
basically is the major OS that doesn't have such wide approach to file
descriptors).

> Since in order to use this for doing some client-side tunnelling the http
> server must meet some specific requirements and option --no-buffer must be
> used as well, why isn't all this behind a non-default curl option?

No, I don't think that's the situation.

A HTTP server can very well start sending its response before the client is
done sending its request so it makes sense to allow the server to continue
provide its data even if the uploading from the client stalls for a while. (In
fact I did one of the first ever libcurl overhauls back in the early days
simply because of a such both-directions simultaneously case.)

I don't think --no-buffer is strictly necessary for this feature to work, it
will just make it work better for some (most?) cases.

So no, I don't see a reason for a new option for this feature as I think it
blends in fine already with the existing ones.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html