commit 4fab33118efc47ea9fc567c240b00008710e7607
from: Omar Polo <op@omarpolo.com>
via: Thomas Adam <thomas@xteddy.org>
date: Mon Apr 29 12:22:32 2024 UTC

got-notify-http: fix I/O with TLS (again)

We try to handle early replies from the server, so we call tls_read()
at each "tick" of the event loop.

For the TLS case, however, bufio_read() will set bio->wantev, and
if we rely only on it we can deadlock trying to read data from the
server without having sent all the request.

Found out the hard way while trying to send several notifications
in one go.

ok stsp

commit - 6d3ee6a573cbed36117e77d6358171ca3474fd75
commit + 4fab33118efc47ea9fc567c240b00008710e7607
blob - 03cef677989c30438df23619e9eaea3e8be77f21
blob + 8f5c7c4ec82547aac85eaa8e00be8b760ce44a99
--- gotd/libexec/got-notify-http/got-notify-http.c
+++ gotd/libexec/got-notify-http/got-notify-http.c
@@ -813,6 +813,16 @@ static inline int
 bufio2poll(struct bufio *bio)
 {
 	int f, ret = 0;
+
+	/*
+	 * If we have data queued up, retry for both POLLIN and POLLOUT
+	 * since we want to push this data to the server while still
+	 * processing an eventual reply.  Otherwise, we could wait
+	 * indefinitely for the server to reply without us having
+	 * sent the HTTP request completely.
+	 */
+	if (bio->wbuf.len)
+		return POLLIN|POLLOUT;
 
 	f = bufio_ev(bio);
 	if (f & BUFIO_WANT_READ)