Re: CGI Child Process Question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux