// Otherwise copy non-header data to response buffer and set state to read response.
_response = bp;
The body of the response starts at (bp) and is (_contentLength)
bytes long. The goal here is to set _response (a string member
variable) to be a copy of the response body.
So, what's wrong with this picture?
The code fragment above invokes string::operator=(const char*),
which copies from the pointed-to character up to (but not
including) the first null character. Problem is, the body might
(I speak from embarrassed experience) have a null character
('\0') in it. In that case, _response will only have part of the
response body. XmlRpc++ will then get very confused about what
it's read and what it has to read, and will end up trying to
read "the rest of the response" (which will never arrive).
There's a form of string::assign() that takes both a pointer and
a length, that should work much better.
Hope this helps. --PSRC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Consider the following code fragment:
XmlRpcUtil::log(4, "client read content length: %d", _contentLength);
// Otherwise copy non-header data to response buffer and set state to read response.
_response = bp;
The body of the response starts at (bp) and is (_contentLength)
bytes long. The goal here is to set _response (a string member
variable) to be a copy of the response body.
So, what's wrong with this picture?
The code fragment above invokes string::operator=(const char*),
which copies from the pointed-to character up to (but not
including) the first null character. Problem is, the body might
(I speak from embarrassed experience) have a null character
('\0') in it. In that case, _response will only have part of the
response body. XmlRpc++ will then get very confused about what
it's read and what it has to read, and will end up trying to
read "the rest of the response" (which will never arrive).
There's a form of string::assign() that takes both a pointer and
a length, that should work much better.
Hope this helps. --PSRC