Parse and generate HTTP2

[Keksoj]

complete parsers and generators for HTTP2

[Sytten]

Hey! Just checking if you guys are still planning on working on this parser? Anyway plan to support http3 after that?

[StevenLeRoux]

Hi @Sytten

The parsing is fairly complete and we are intensively testing the H2 implementation (which is already working with gRPC use cases).

We also plan to support HTTP3 after a proto layered refactoring.

[Sytten]

Great to hear!

Just a small suggestion, I tried to use kawa to build requests from scratch (instead of parsing) and it wasn't obvious. I kinda gave up.

I would also add a separation of head and body otherwise it's hard to say add a header if you have the full request already parsed.

In general you have a lot of public properties and methods in the object that could be locked down to help users go in the (right) direction.

[Wonshtrum]

Hi @Sytten! Thank you for your interest in this project.

Regarding the HTTP2 progress, it's not immediately visible in this repository as the development is primarily happening in Sozu, the reverse proxy for which Kawa was created.
We plan to merge the parsing and message management here once everything is stable. While this process might not be ideal, it was initially uncertain how some primitives would be translated and exposed in Kawa.
As for Kawa's broader purpose outside of Sozu, we're still finalizing our vision for it. This partly explains why many aspects are currently public and basic.
We do have plans for a more convenient Request/Response builder. However, with the introduction of HTTP2, we're also reevaluating parts of the design and memory layout, which might introduce some delays.

Your feedback and suggestions are greatly appreciated, and we're working to make Kawa more user-friendly.
Thank you for your understanding and patience as we continue to evolve the project.

[Sytten]

@Wonshtrum All good! We are also building a reverse proxy but for security testing (Caido). If you want help on design / implementation let me know.

In our usecase we do a lot of transformation of the body on the fly like removing TE and CE. We also accept all payloads including invalid ones, so our parsing is best effort. Like sometime we will see leaked data so the body might contain both a chunked data and something else at the end so we process the chunked and keep the extra data unparsed.

We use both generic primitives (first line, line by line header) and best effort precise primitives (method, header name, header value). Having both served by the same in memory representation is challenging.

[Wonshtrum]

Thank you for sharing insights about your project! It's interesting to learn about the challenges you're addressing, especially with dynamic body transformations and handling potentially invalid payloads.

I'm curious about your use case for Kawa and if you are considering using it in Caido or something else. Your perspective outside of Sozu would be greatly valuable. We appreciate any suggestions or insights you can provide, as we are actively looking to enhance Kawa and make it more versatile for a broader range of projects.

Currently, we're considering rewriting most of Kawa internal representation, making it faster, safer, and lighter, with the aim of reducing its memory footprint by as much as half. Additionally, we're exploring ways to expose some HTTP2 primitives, such as header compression.