Nate Lawson <[EMAIL PROTECTED]> writes:
> May I humbly propose that the API is broken and should be reworked? My
> frustration with cached_connection common/ftp sharing and this thrashing
> trying to overload the return value are signs that the API needs
> rethinking.
What do you mean "overload t
On Wed, 30 Oct 2002, Dag-Erling Smorgrav wrote:
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > I'd rather fix it like this:
>
> Oomph, of course this doesn't work in the !ssl case. I would really
> prefer a solution that allowed wlen == 0 if we actually *intended* not
> to write anything,
I was working on (wlen == 0 && iov->iov_cnt != 0) for a while, thinking
that it would work in both cases, even though the logic is a little weird
in the writev case, but it would fail in the race where the connection
closed at the same time as the writev() with the zero length iov_len.
Bill
To
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> I'd rather fix it like this:
Oomph, of course this doesn't work in the !ssl case. I would really
prefer a solution that allowed wlen == 0 if we actually *intended* not
to write anything, but I can't figure out a clean, quick way to do it
right now
Bill Fenner <[EMAIL PROTECTED]> writes:
> Turns out my writev patch for fetch broke SSL, since it could create
> iov[0].iov_len = 0, which would cause SSL_write(..,0), which would
> return 0, which would look like a short write and cause an error, which
> then gets ignored by http.c . Ignoring the
On Tue, Oct 29, 2002 at 07:12:25PM -0800, Bill Fenner wrote:
> then gets ignored by http.c . Ignoring the bigger picture of the error
> checking, this fix at least gets https: working again by making sure
> that _fetch_putln doesn't construct an iov with iov_len == 0. (Yes,
> this is against rev
