The following reply was made to PR os-solaris/3467; it has been noted by GNATS.
From: Marc Slemko <[EMAIL PROTECTED]> To: "Christopher W. Curtis" <[EMAIL PROTECTED]> Cc: Apache bugs database <[EMAIL PROTECTED]> Subject: Re: os-solaris/3467: Broken client connections not detected Date: Wed, 2 Dec 1998 09:42:17 -0800 (PST) On Wed, 2 Dec 1998, Christopher W. Curtis wrote: > Marc Slemko wrote: > > > > On Tue, 1 Dec 1998, Christopher W. Curtis wrote: > > > > > be it. PHP does not patch anything in Apache, and I am 99.997% sure > > > that PHP is using the Apache-style read/write calls (PHP implements > > > > Yea, but it can do it wrong. > > Ahh. Hmm. > > > If it is inside an ap_soft_timeout then php needs to be checking > > r->connection->aborted and the return value from the write functions. > > > > There are many many modules that do handle this properly. > > Okay ... here's a message I composed yesterday: > > --- > I purposefully broke a connection and truss'd it. The first write after > the connection was broken gives no error. The second write gives: > > write(6, " < f o n t c o l o r =".., 198) Err#32 EPIPE > Received signal #13, SIGPIPE [ignored] > alarm(0) = 0 > sigaction(SIGALRM, 0xEFFFE780, 0xEFFFE830) = 0 > sigprocmask(SIG_BLOCK, 0xEFFFE820, 0xEFFFE810) = 0 > alarm(10) = 0 > sigsuspend(0xEFFFE800) (sleeping...) > > ... and then it continues to try to write as the page continues to spit > out data. The server-status handler shows two active processes writing, > where there should only be one. Contrary to what I said before, there > are no open ports associated with the child that ignores SIGPIPE and > continues to run. Another truss gives: > > read(7, "05 C h r i s\t 9 1 2 5 6".., 55) = 55 > read(7, "01\0\0\n", 4) = 4 > read(7, "FE", 1) = 1 > alarm(0) = 0 > sigaction(SIGALRM, 0xEFFFE780, 0xEFFFE830) = 0 > sigprocmask(SIG_BLOCK, 0xEFFFE820, 0xEFFFE810) = 0 > alarm(10) = 0 > sigsuspend(0xEFFFE800) (sleeping...) > > That first line is data that *should* be written to the browser. It > looks like Apache has given up trying to write anything entirely. Maybe > this is a better indication of what is going on. Maybe the signal > handler sets some flag that isn't fully qualified? Just guessing... There are any number of things it could be doing, but I have seen no reason to think that Apache is doing anything wrong. As I said before, there are many many Apache modules that do handle this thing just fine. There are also many ways to use the Apache API that will cause it to not work properly. We can't debug every third party module out there, so unless you have some reason to think this is something inherent to all modules and not just a problem of php...
