The nature of this project does allow me to reveal any details. This thread is closed, I'm not here to argue with 10s of unknown people on the Internet. -----Original Message----- From: André Warnier [mailto:aw@xxxxxxxxxx] Sent: Saturday, March 21, 2009 4:37 PM To: users@xxxxxxxxxxxxxxxx Subject: Re: Re: CGI Child Process Question Lihet Ruben wrote: > Well, I don't know better. I didn't knew at all before I emailed the list. > At first, I made an assumption, and I wanted someone to confirm it. Mean > time, I did reasearch on how it works and I found an answer, then share it > to the community ;) > > Don't be mad at me :D > Well, maybe I, and other people on this list, have some reasons to feel a bit disappointed, after spending time trying to give you tips ? "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." That may be true under certain MPM's (threaded ?), but is certainly not universal. Anyway, it does not change the fact that the cgi-bin is a different process than Apache, and it does not change the fact that your script may think that it has sent all the data, but that your client has not received it all. "But anyway, I think that the SIGPIPE signal has the same effect as an Apache Filter." Not quite. They are two totally different things. "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." Not at all. Your cgi-bin may get a SIGPIPE (from the O.S., not from Apache) when /it/ finds /its/ own output stream closed when trying to write to it. More likely, he'll just get an I/O error. "Apache routes the stdout from my cgi-script to the clients socket through a pipe," No, it does not. Apache reads the output of your script, stores it in buffers (bucket brigades), and passes these further down the chain of Apache filters, in case anyone else wants to examine the output. And finally, it is Apache that sends the data to the client, not your script. That's because it is with Apache that the client has a connection, not with your script. "After all, I am not interested if the client has received 100% of the data." Really ? then what was this ? "The most important thing is I want to know if the person has downloaded the file completely or canceled the download." I was always under the impression that "completely" and "100%" were kind of equivalent terms. Now, you can ask questions, but if you change the questions after people have answered them, it's a bit unfair, isn't it ? "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." That paragraph does not really make much sense, and seem to contradict itself several times. So basically, what do you really want to know ? And are you interested in good tips and explanations, or just in confirming your misconceptions ? --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|