http_request body will be purged after calling http_client::request()

[evakili]

It is a simple code to test this issue (or as designed feature):

#include <cpprest/http_client.h>
using namespace web::http;

int main() {
	try {
		auto client = client::http_client{ U("https://jsonplaceholder.typicode.com/") };
		auto request = http_request{ methods::POST };
		request.set_request_uri(U("/posts"));
		web::json::value requestData;
		requestData[L"title"] = web::json::value::string(U("hello!"));
		requestData[L"body"] = web::json::value::string(U("It is a salutation..."));
		requestData[L"userId"] = web::json::value::number(100);
		request.set_body(requestData);
		auto response = client.request(request).get();
		// here request has no body, but other attributes of it such as headers are remained unchanged
		std::wcout << response.status_code() << std::endl;
	}
	catch (std::exception& e) {
		std::cout << e.what() << std::endl;
	}
    return 0;
}

Why after calling http_client::request(http_request) the body is being emptied? The argument is passed by value and I expect no side effects on it. I guess that the root of this behavior is in using a shared istream (i.e. http_msg_base::m_inStream) between instances of copied http_request that its data is consumed in call to http_client::request(http_request). But it is confusing and against principle of least astonishment.

[weltkante]

The body has to be consumed to send the request, it's a stream after all, that doesn't sound like a violation of the 'principle of least astonishment' but an application of 'you do not have to pay for features you do not use'. Streams can also be based on ad-hoc computations (for example streaming a file upload with compression), so if the caller wants to retain a copy of stream content for later inspection he is responsible to set everything up for this himself.

However, if streams may not be rewindable, following the 'principle of least astonishment' it shouldn't even be possible to retrieve the body of a request-to-be-sent in the first place. The consumer of the stream is supposed to be the http_request and not someone who tries to look at the body and thus using up the potentially single-use stream.

So the 'real' problem here is that http_client and http_listener share the same http_request class for different purposes (sending and retrieving requests). Both have a different but overlapping set of APIs which for some reason has been implemented on the same class instead of subclasses. So you are supposed to only use APIs which are valid for the use-case of a http_client; retrieving the body of a request should conceptually be reserved for the use-case of a http_listener.

[evakili]

@weltkante:
The question is not about streams, but http_client::request(). Sending an object by value means that a copy of that object should be consumed and the original one (its body and other states) should be remained unchanged. The signature of http_client::request() is as follow:

pplx::task<http_response> http_client::request(http_request request, const pplx::cancellation_token &token);

Using streams for handling body of an HTTP message is good for some scenarios but here it causes a not so serious problem.