Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 92683 invoked from network); 21 Mar 2009 12:10:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Mar 2009 12:10:22 -0000 Received: (qmail 91077 invoked by uid 500); 21 Mar 2009 12:10:11 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 91055 invoked by uid 500); 21 Mar 2009 12:10:11 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 91046 invoked by uid 99); 21 Mar 2009 12:10:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Mar 2009 05:10:11 -0700 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=MISSING_MID,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of ruben.lihet@my.fmi.unibuc.ro does not designate 81.196.12.70 as permitted sender) Received: from [81.196.12.70] (HELO smtp.rdslink.ro) (81.196.12.70) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Mar 2009 12:10:03 +0000 Received: (qmail 14270 invoked from network); 21 Mar 2009 12:09:41 -0000 X-Mail-Scanner: Scanned by qSheff-II-2.1-r3 (http://www.enderunix.org/qsheff/) Received: from unknown (HELO nbruben) (79.115.141.190) by smtp1.rdslink.ro with SMTP; 21 Mar 2009 12:09:41 -0000 From: "Lihet Ruben" To: , Date: Sat, 21 Mar 2009 14:09:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <49C4C963.9080202@ice-sa.com> Thread-Index: AcmqFWc/5NSMS8amQemX92ueaz07hQABszSA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Checked: Checked by ClamAV on apache.org Message-Id: <20090321121010.E963C7248B6@athena.apache.org> Subject: [users@httpd] Re: CGI Child Process Question Andr=E9 Warnier wrote: "A cgi-bin program is a separate process from the Apache child that runs it." My tests (and the whole cgi logic in a web server) concluded that the cgi-script is a child of apache. This because the the ppid() of the cgi-script is the pid() of the apache server daemon. ;) Thanks for the tip, I haven=92t thought on using an Apache Filter. But = anyway, I think that the SIGPIPE signal has the same effect as an Apache Filter. = I'm not sure, but I think Apache already has filters that send this kind of singnals to the cgi-script when the socket is closed. That's what = SIGPIPE is all about. Apache routes the stdout from my cgi-script to the clients = socket through a pipe, when the socket is closed, apache sends a SIGPIPE the my cgi-script telling that the client has disconnected. After all, I am not interested if the client has received 100% of the = data. I am interested to know, how close to 100% did the client received. The cgi-script I'm writing, is a bit selfish. All he wants to know is yes or = no, how much data did the client wasted on his request. If the data was not = 100% received by the client because he cancelled, that's his problem, he can request again later.=20 -----Original Message----- From: Andr=E9 Warnier [mailto:aw@ice-sa.com]=20 Sent: Saturday, March 21, 2009 1:03 PM To: users@httpd.apache.org Subject: Re: [users@httpd] Re: CGI Child Process Question Lihet Ruben wrote: [...] I would look at this in another way. A cgi-bin program is a separate process from the Apache child that runs it. The Apache process starts the cgi-bin process, and arranges to read back everything that the cgi-bin writes to STDOUT. Then Apache sends this to the browser. In-between, there is buffering, so as someone pointed out, it is possible that after your cgi-bin has already finished its job of producing the output and has exited, Apache is still busy sending some chunks of output to the browser, and then the user cancels. In that case, your script would think that everything has been sent, while this is not the case. What I would thus do, is to implement your logic of verifying that the user has received everything, in an Apache output filter. It is still not perfect, but much "closer" to the browser. If the user interrupts the connection by hitting cancel, the filter would know, because it would get an i/o error when writing to the response socket. And it could notify your application. Now understand that if your client is behind a proxy that does buffering, then the proxy will still hold some data, while Apache is long done and the filter has told your application that everything was sent. And the user can still hit cancel then. So ultimately, to be 100% sure, the only solution is to ask the user, when he has finished downloading, to acknowledge receipt. I cannot think of an easy way to do that with a standard browser, but I can imagine a Java applet which gets the file from your server, writes it to a local file, and when it is done, makes a POST to the server to say it was done. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server = Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org