Design Note: Unified Request/Response for Parsing & Writing

[StormLord07]

When I started reimplementing the Request/Response in the strict_parsing branch, I had the idea to create a single “all-mighty” Request/Response class. The vision was that a user could recover even from failed parses (for example, due to malformed input), while still having the simplicity of working with only two objects: Request and Response.

As I explored this approach, it became apparent that it introduces significant complexity:

• The class quickly bloats with fields for parser and serializer states, or one unified state class becomes too big, protocol-specific data, states (HTTP/1, HTTP/2, HTTP/3), buffers, and policy information. (I did a not so thurrough look through the HTTP2 and HTTP3 specifications again, and it doesn't seem like I could unify all of them cleanly)
• Parsing and writing states clash inside the same object: a Request could be simultaneously “partially parsed” and “partially serialized,” which creates ambiguous lifetimes and makes reasoning about correctness very difficult.
• HTTP/2 and HTTP/3 introduce streams, interleaved frames, and asynchronous header/body processing, which do not fit naturally into a single object. Since the parsing is now multi step, one step is the connection, and second is the stream specific parsing.
• Temporary buffers, partial header fragments, and flow-control bookkeeping would all have to live inside the Request/Response object/subobject, further coupling ideas that should be separate.
• Recovery from error is not safe, requires deep knowledge of the RFC, and involves a lot of copying data, which is not ideal

Because of these issues, I decided to cut this approach for now. Once the core deisgn of "strict, straight-to-structure" is implemented I'd like to revisit the idea in a more clean way, but for now the idea of possible error recovery will not be explored further.

Feel free to comment on the idea, if you think it'd be usefull, I'd be happy to hear your thoughts.