Http server post data to php-cgi using C++ - php

Question

I'm writing a simple http server and I'd like to use php-cgi to handle POST requests. I write the handlePOST as follows:
void KServer::handlePOST(int sockfd, string file, string pdata){
char* argvs[MAX_PARAMS];
argvs[0] = const_cast<char*>(CGI_PATH);
argvs[1] = const_cast<char*>(file.c_str());
stringstream ss;
ss<<pdata.length();
string clen, sname;
ss>>clen;
clen = "CONTENT_LENGTH=" + clen;
sname = "SCRIPT_FILENAME="+file;
char* env[] = {
"REQUEST_METHOD=POST",
"REDIRECT_STATUS=CGI",
const_cast<char*>(clen.c_str()),
const_cast<char*>(sname.c_str()),
"CONTENT_TYPE=application/x-www-form-urlencoded",
0
};
istringstream stream(pdata);
cin.rdbuf(stream.rdbuf());
execve(argvs[0], argvs, env);
...
I know that php-cgi get POST data from STDIN. And I put the POST data (var. pdata) into cin.rdbuf. However, the program fails to fetch data from STDIN when executing execve. But if I enter the string using console, the program can run correctly.

Answer 1

It is highly improbable that when your custom http server reads the socket, it always manages to read exactly the number of bytes in the header portion of the HTTP message before getting to this point; so that when it executes the external process, the body portion of the message, containing the POST data, is now waiting to be read, on its standard input.
More than likely, you are using the C++ I/O library, or maybe even the C stdio library, to read the standard input, or socket. Which means, of course, that the built-in input buffering, that's employed by iostreams or stdio, has already managed to swallow a good chunk of the POST data from the body of the HTTP message, that immediately follows its header. It's now waiting or you, to continue reading on your std::cin, stdin; or whatever your code is actually reading.
It therefore follows that, sadly, when you execute the external process, it will be dismayed to find that the POST data it expects has already been consumed, either in entirety, or in part, on its standard input. Instead, it's sitting right here, in your process, waiting for you to resume reading your std::cin, stdin, or whatever.
In other words, for this to work, you cannot just execute an external process, and wash your hands of the whole mess. You will need to set up a pipe to the external process's standard input, and it is your responsibility to proceed to meticulously read the body of the HTTP message, that forms the POST data, just like you've just now finished reading its header, and then dump it into the pipe.
That means parsing the Content-Length header, to know exactly how many bytes are in the body, and reading exactly that (because you're not going to get an EOF, and rely on it, since the socket will remain open for your expected HTTP reply).
And, of course, you will also then need to carefully handle everything that happens as a result of writing to a pipe, i.e. gracefully handling the reader shutting down before consuming the entirety of the piped data, resulting in a broken pipe, etc...