[FASTCGI] Return application octet-stream data

Noah Silverman noah at smartmediacorp.com
Tue Sep 18 17:41:48 EDT 2012


Hi,

It looks like I'm still having a bit of trouble.

Thanks to Jay's help, I can reliably return a binary string from the fastcgi program back to the webserver(and remote connection).

I've noticed that about 50% of the *incoming* requests aren't getting parsed properly.  All incoming requests are sent as post data of an octet-stream.   My guess is that the way I'm reading them in isn't happy with a null character or something similar.  

Any ideas on how to fix this one?  I imagine that there is a "best practices" way to safely read in the post data from nginx.

Thanks!

Here is the c++ snippet:  
(Taken from the example script supplied with fastcgi.)

============================================
static long gstdin(FCGX_Request * request, char ** content){
    char * clenstr = FCGX_GetParam("CONTENT_LENGTH", request->envp);
    unsigned long clen = STDIN_MAX;
    if (clenstr){
        clen = strtol(clenstr, &clenstr, 10);
        if (*clenstr){
            cerr << "can't parse \"CONTENT_LENGTH="
                 << FCGX_GetParam("CONTENT_LENGTH", request->envp)
                 << "\"\n";
            clen = STDIN_MAX;
        }

        // *always* put a cap on the amount of data that will be read
        if (clen > STDIN_MAX) clen = STDIN_MAX;

        *content = new char[clen];

        cin.read(*content, clen);
        clen = cin.gcount();
    }
    else{
        // *never* read stdin when CONTENT_LENGTH is missing or unparsable
        *content = 0;
        clen = 0;
    }

    // Chew up any remaining stdin - this shouldn't be necessary
    // but is because mod_fastcgi doesn't handle it correctly.

    // ignore() doesn't set the eof bit in some versions of glibc++
    // so use gcount() instead of eof()...
    do cin.ignore(1024); while (cin.gcount() == 1024);
    return clen;
}

int main (void){

    // Backup the stdio streambufs
    streambuf * cin_streambuf  = cin.rdbuf();
    streambuf * cout_streambuf = cout.rdbuf();
    streambuf * cerr_streambuf = cerr.rdbuf();

    FCGX_Request request;

    FCGX_Init();
    FCGX_InitRequest(&request, 0, 0);
	
	//The main loop for fast cgi
	  while (FCGX_Accept_r(&request) == 0){
		char * content; 
		unsigned long clen = gstdin(&request, &content);
		etc…
		….
	}
	return 0;
}
============================================



On Sep 18, 2012, at 2:24 PM, Charles Thomas <charles_thomas at mac.com> wrote:

> Yeah... it's a real love-hate relationship for me.  I love fixing the problems that I Hate getting.
> 
> The weirdest one I have had with FastCGI was cross-domain transfer from a javascript to fastcgi.  With that one there were some weird requirements concerning what headers I could and could not have in the request/response. 
> 
> Speaking of headers and fastCGI, are there any classes that encapsulate the header logic into them?  I know about the fastcgi library, and one for Qt  (FastCgiQt), but I was wondering if there are any more higher level classes out there?
> 
> Tom
> 
> Sent from my iPad
> 
> On Sep 18, 2012, at 3:54 PM, Jay Sprenkle <jsprenkle at gmail.com> wrote:
> 
>> My guess is that was the issue.
>> The other (terminating the string at the first zero byte) might have caused similar problems as well.
>> Computers are so fussy ;)
>> 
>> 
>> On Tue, Sep 18, 2012 at 3:49 PM, Charles Thomas <charles_thomas at mac.com> wrote:
>> i guess it would help if I read the entire mail message :)... so it was the missing Content-Length?
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.fastcgi.com/pipermail/fastcgi-developers/attachments/20120918/ffa9d99d/attachment-0001.html>


More information about the FastCGI-developers mailing list