[FASTCGI] Return application octet-stream data

Charles Thomas charles_thomas at mac.com
Tue Sep 18 13:48:33 EDT 2012


>From what I understand of HTTP protocol Content-Length is used to determine how long the message is... not the occurrence of a null character in the data stream; and that content length starts after the newline separating headers from data.

Some thoughts:

1) Did you separate the headers with a "\n" from the body
2) Is the content length truly the length of the data
3) Does the mime type have to be set correctly in order for server you are talking with to recognize,
4) Some times I have found that servers expect the Accept tag to contain specific reference to the type of file.


Sent from my iPad

On Sep 18, 2012, at 12:36 PM, Noah Silverman <noah at smartmediacorp.com> wrote:

> Very possibly,  
> 
> But since I don't control the serialization I have no way to manage that.
> 
> Is there a way to force fastcgi to ignore a zero byte?
> 
> --
> Noah Silverman
> Smart Media Corp.
> 
> 
> 
> On Sep 18, 2012, at 10:28 AM, Jay Sprenkle <jsprenkle at gmail.com> wrote:
> 
>> Just a wild guess:
>> Perhaps your serialized data contains a byte containing zero which is being taken as an end marker (prematurely terminating the response)?
>> 
>> On Tue, Sep 18, 2012 at 11:38 AM, Noah Silverman <noah at smartmediacorp.com> wrote:
>> Hello,
>> 
>> I am attempting to write a small CGI client in C++ that will use Google's protocol buffers to manage data.  I am using the latest release of fast cig, with Nginx.
>> 
>> Google's protocol buffers library serializes a string into a "binary format".  I need to be able to send that format back as a response.  (Details on the format are here: https://developers.google.com/protocol-buffers/docs/encoding)
>> 
>>  My test program sends an POST request to the server, and expects an application/octet-stream back of a serialized string from the CGI script.
>> 
>> I am able to start and run the application fine.
>> 
>> My CGI code is able to successfully receive the POST and pass the data fro the received string.  That works great.
>> 
>> The problem is in returning back a response.  I am able to create and serialized a proper response (using protobuf library).  I can then dump the contents to a log file and verify that they are perfect.  HOWEVER, the receiving program is unable to recognize the binary response sent back from the CGI.  Somehow, it is getting mangled in sending the response.  I can't figure out why.
>> 
>> Any and all suggestion are welcome.
>> 
>> Thank You,
>> 
>> --
>> Noah
>> 
>> Relevant code snippets:
>> 
>> 
>> CGI snippet
>> ==========================================================
>> string post_response;
>> bid_response.SerializeToString(&post_response)
>> cout << "Status: 200 OK\r\n";
>> cout << "Content-type: application/octet-stream\r\n\r\n";
>> cout << post_response << "\n";
>> 
>> 
>> Nginx config
>> ==========================================================
>> location ~ test.cgi$ {
>>         fastcgi_pass   127.0.0.1:8000;
>>         include        fastcgi_params;
>>         default_type application/octet-stream;
>>         fastcgi_pass_header http;
>> }
>> _______________________________________________
>> FastCGI-developers mailing list
>> FastCGI-developers at mailman.fastcgi.com
>> http://mailman.fastcgi.com/mailman/listinfo/fastcgi-developers
>> 
>> 
>> 
>> -- 
>> ---
>> "Why do you have that banana in your ear?" 
>> "To keep away the alligators."
>> "But there are no alligators here."
>> "See! It's working!"
>> --
>> The Democrats are the left wing.
>> The Republicans are the right wing.
>> We all know how well a bird flies with just one wing.
>> 
> 
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers at mailman.fastcgi.com
> http://mailman.fastcgi.com/mailman/listinfo/fastcgi-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.fastcgi.com/pipermail/fastcgi-developers/attachments/20120918/de6dcc2c/attachment.html>


More information about the FastCGI-developers mailing list