Re: libfetch(3) patch for SSL
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 the return value? _fetch_read(), _fetch_write() and _fetch_writev() are meant to return the same values in the same cases as read(2), write(2) and writev(2) would. The only difference should be in what value errno can have after they return (I don't think any of the system calls can set it to ETIMEDOUT). None of this has anything to do with cached connections, and I do not agree that caching should be done in common.c, because it relies on information (such as login and password) which is not and should not be available at that layer. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
libfetch(3) patch for SSL
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 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 1.40, post-brouhaha).
Bill
Index: common.c
===
RCS file: /home/ncvs/src/lib/libfetch/common.c,v
retrieving revision 1.40
diff -u -r1.40 common.c
--- common.c30 Oct 2002 00:17:16 - 1.40
+++ common.c30 Oct 2002 03:06:58 -
@@ -539,13 +539,18 @@
_fetch_putln(conn_t *conn, const char *str, size_t len)
{
struct iovec iov[2];
+ int ret;
DEBUG(fprintf(stderr, %s\n, str));
iov[0].iov_base = __DECONST(char *, str);
iov[0].iov_len = len;
iov[1].iov_base = __DECONST(char *, ENDL);
iov[1].iov_len = sizeof ENDL;
- if (_fetch_writev(conn, iov, 2) == -1)
+ if (len == 0)
+ ret = _fetch_writev(conn, iov[1], 1);
+ else
+ ret = _fetch_writev(conn, iov, 2);
+ if (ret == -1)
return (-1);
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libfetch(3) patch for SSL
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 1.40, post-brouhaha). This patch does not break pkg_add -r or fetch in my environment. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libfetch(3) patch for SSL
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 Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libfetch(3) patch for SSL
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, but I can't figure out a clean, quick way to do it right now. I guess your patch will have to do for now. 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. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
