FASTCGI and Huge Post Data

Generally speaking, the nature of post data is a stream coming in. To my
knowledge, you need to bring it all in first, before you should respond. I
haven't read this anywhere - but I assume it because to me it makes sense -
read the whole request and then return something.

You mentioned returning something huge. If this is some sort of file return,
then I might consider a special approach, one to receive and another to
send, with required communication to the user via html.

For large or long processing HTML stuff (cuz server cranking on something,
and you don't want to appear to the user as "um... think its going to time
out"... I personally either toss out SOMETHING ... usually a DIV section,
With a please wait or something, followed by little self contained scripts
that modify the DIV... to "Almost done", "4 out of 5 processed" then the
rest of the HTML PAGE clears this div section to nothing, and it usually
means I have a little 1/4 inch of space I can't always reclaim but the user
was never left wondering.

I guess, depending on what you're doing, the approach might be more
important than the FastCGI "issue" you are having.

Jason P Sage

----------Original Below-----------------
Subject: [FASTCGI] Is this a bug for fastcgi C library?

Hi,
These days I spent some time to write a fastcgi module for a scripting 
language using the fastcgi C library. I observe a problem in the library 
when there is a large amount of post data for the request, that is, for 
example, if there is more than 100KB post data which are not processed 
by the fastcgi application, it becomes impossible to send back to the 
server a large mount of data (500KB), in this case, the fastcgi 
application seems to be blocked somewhere. But if the fastcgi just send 
a small amount data, this problem do not exist, and also if the just a 
small amount of  post data not processed before sending many data, this 
problem will not happen. Though one can alway avoid this problem by 
processing all the post data before sending a large amount of data, it 
would be nice if this problem will be removed.
Regards,

Limin

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/



-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.3/394 - Release Date: 7/20/2006


___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/