boostorg / boostorg/beast

Serialization state is part of message

Open
#1,810 8 comments 0 reactions 0 assignees View on GitHub
Design
Dominant language
C++
Stars
4.8k
Forks
694
Avg merge
12h 48m
Merged PRs (30d)
1

Description

I think it would be nicer if the message was const and all the serialization state was in the serializer. Is there any reason why this is not so?

The problem I'm having is this: I'm writing a HTTP client and I want to reuse a connection for subsequent requests. If the request fails (for a limited set of reasons, including that the server closed the connection in the meantime), I need to re-connect and then re-send the request.

Due to the way I structured the method, I only start reading after sending the request (otherwise I might notice the dropped connection earlier).

The issue now is that the error due to dropped connection sometimes occurs only after serializing part of the request body (for instance, a file upload). Then I re-connect, re-create the serializer and re-send the request. The problem with this is that in case of a file upload, the basic_file_body contained in the request does no longer point to the beginning of the file. In the end this leads to an infinite loop, where I wait for `serializer::is_done()` to become true, which never happens, because not enough bytes come out of the file_body, due to the bytes consumed by the first, failed, request.

I don't see a way to reset the state of the body at that point in the code, since I don't know the body type, and even if I did, the only way to reset the file body seems to be to re-open the file, for which I would need to know the filename.

Maybe it would be good if each body type had a reset() function, to reset its state?

If there's a better way to accomplish what I want, I'm all ears...

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.