I'm sure there's a great reason for setting B_EOUT flag here, but it
sure does suck if you have data waiting to be sent to the client since
setting B_EOUT convinces ap_bclose() not to write any more data.
In trying to recreate a real world problem, I am using a handler that
does
ap_rwrite(1 byte buffer)
ap_rflush()
ap_rwrite(80000 byte buffer)
ap_rflush()
ap_rwrite(1 byte buffer)
ap_rflush()
and the client doesn't get an ending chunk. The ending chunk is
sitting in the BUFF when set hit the code I changed below.
(ap_rputs() put it there.)
If I slow things down (e.g., with a debugger) so that FIN from client
comes before we hit the logic I changed, ap_bhalfduplex() will flush
before we hit the troublesome ap_bsetflag(conn_io, B_EOUT, 1) that I
commented out.
Unfortunately, that setting of B_EOUT was committed with a boatload of
other changes so I'm not hopeful that I can find a description of what
it solved.
Index: src/main/http_main.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.594
diff -u -r1.594 http_main.c
--- src/main/http_main.c 1 Oct 2002 14:24:23 -0000 1.594
+++ src/main/http_main.c 19 Oct 2002 00:19:16 -0000
@@ -5972,7 +5972,10 @@
lingering_close(r);
}
else {
- ap_bsetflag(conn_io, B_EOUT, 1);
+ /* YOY? setting B_EOUT keeps ap_bclose() from writing remaining data
+ *
+ * ap_bsetflag(conn_io, B_EOUT, 1);
+ */
ap_bclose(conn_io);
}
#endif
Comments or suggestions?
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
