WSF Staff itself does not have any limitations for response size. Internally it's processed by AxiOM (Axis2/C object model), which may introduce the limitations.
When using axis2c-unofficial I cannot reproduce it.
As example, this is my test service:
class TestBase64: public staff::IService
{
public:
// *restEnable: true
// *restMethod: GET
// *restLocation: test
virtual staff::base64Binary test() = 0;
};
// impl:
staff::base64Binary TestBase64Impl::test()
{
staff::ByteArray a(4 * 1024 * 1024);
staff::byte* b = a.GetData();
for (int i = 0, l = a.GetSize(); i < l; ++i) {
b[i] = static_cast<staff::byte>(i);
}
return staff::Base64Binary(a);
}
and client:
const staff::base64Binary& ttestResult = pTestBase64->test();
staff::LogInfo() << "test result: " << ttestResult.ToString().size();
Suggestions:
- use network capture software (Wireshark) to detect on which side is the problem, if you see full packet which comes from server, the problem is on client side;
- try axis2/c unofficial;
- try the service provided, and open the url on browser: http://localhost:9090/axis2/services/TestBase64/test ;
- try libxml2 parser instead of guththilla (as last resort);
If nothing helps you could try to save the binary data as temporary file on web server and response with the url to that file and download that file on client separately;